Added CVE-2016-15043 template

[D3nverNg]

/claim #14673

PR Information

The payload is based on the Metasploit framework PoC. However, interactsh-url does not allow uploading files from an external source; it can only be used to trigger file creation and confirm the existence of the file on the target host.

• Added CVE-2016-15043 template
• References:
  • https://nvd.nist.gov/vuln/detail/CVE-2016-15043
  • https://wpscan.com/vulnerability/
  • https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/unix/webapp/wp_mobile_detector_upload_execute.rb

Template validation

• Validated with a host running a vulnerable version and/or configuration (True Positive)
• Validated with a host running a patched version and/or configuration (avoid False Positive)

Additional Details (leave it blank if not applicable)

Vulnerable version:

• Normal scan:

• Scan with -debug:

Patched verrsion:

• Normal scan:

• Scan with -debug:

Additional References:

• Nuclei Template Creation Guideline
• Nuclei Template Matcher Guideline
• Nuclei Template Contribution Guideline
• PD-Community Discord server

[D3nverNg]

Hi @pussycat0x , I’ve updated the template with all required changes and have already sent the setup environment to templates@projectdiscovery.io. Could you please review my PR?

[Sourabh-Sahu]

Hi @pussycat0x,

@D3nverNg initially uploaded an incomplete/dummy template without proper local validation, only to secure the “first submit” position.
After a few hours, they updated and fixed the template.

This approach is unfair to other contributors who spent proper time ensuring accuracy and validation before submission.

Submissions should only be considered valid when they are properly tested and verified at the time of submission — not updated later just to retain priority.

I request the team to please review this behavior so that the contribution process remains fair for everyone.

[D3nverNg]

Hi @pussycat0x,

@D3nverNg initially uploaded an incomplete/dummy template without proper local validation, only to secure the “first submit” position. After a few hours, they updated and fixed the template.

This approach is unfair to other contributors who spent proper time ensuring accuracy and validation before submission.

Submissions should only be considered valid when they are properly tested and verified at the time of submission — not updated later just to retain priority.

I request the team to please review this behavior so that the contribution process remains fair for everyone.

Hi, I’d like to clarify the timeline of my three commits:

• Jan 2 2026, 09:04 AM GMT+7 | commit f607906 – This was when I wrote the initial program, based on a PoC I had found, so I committed it and opened a PR.
• Jan 2 2026, 10:21 AM GMT+7 | commit b050ed6 – After creating that PR, I started rebuilding the necessary environments so I could share them with the team. Once the environment was set up and I began debugging the template again, I realized there were several issues and revised the PoC based on the Metasploit Framework.
• Jan 2 2026, 11:03 AM GMT+7 | commit bda9f74 – This was the final commit, made after I sent the complete environment to the ProjectDiscovery team via email. I refined the code so the output would be more concise and accurate, and added supporting screenshots to the PR.

Sorry for the misunderstanding. I’m new to this field, so once I completed the template, I wanted to open a PR as quickly as possible (I was even nervous enough to leave a mistaken comment on the issue page 😢 ). I also wasn’t sure whether the team reviews and awards bounties based on the quality of the template in the initial commit or on the submission time. I only knew that my first template had issues, so I wanted to fix them.

Thank you for your attention and feedback. I’ll be more careful next time.

[thewindghost]

Hi @Sourabh-Sahu. Good a day!

Before accusing someone of bad faith, please ask what happened first. Here's what actually occurred:

• File naming confusion: D3nver initially named files "test" instead of "CVE-2016-15043.yaml", causing .txt/.yaml mix-up And that stored .txt version was copied from the Google Meet chat (updated to avoid misunderstandings).
• Two PoC versions existed: One working, one not. D3nver accidentally copied the non-working version during our Google Meet session - the free version only allows copying and pasting; it doesn't allow sending files
• And Later I reviewed his PR, found the error, called him to fix it. He submitted the wrong file due to the mix-up
• This is the POC he pushed to GitHub. The requirement was that it be complete and submitted to me for review, but I checked it on the PR before reading this one.
  

This was an honest mistake with file confusion, not intentional gaming. Nobody forbids fixing errors after submission - that's literally what version control is for. Issue with your response Instead of asking for context, you used AI to write a formal complaint. That's not how community collaboration works. Next time, ask for clarification before claiming unfair play.

If you prefer to talk about milestones, you can check for yourself that he also edited his own PR, but he did it 10 minutes after D3nverNG, which is 10:21 (D3nver) and 10:31 (KrE80r). So, based on what you said, is he still ahead? (if you understand it that way)

[Sourabh-Sahu]

Hi @princechaddha, @pussycat0x,

Let me clarify my concern — this is not about whether @D3nverNg or @KrE80r submitted first. The concern is about the without validation the template submitted and accure the first position on the issue.

Please review the timeline for this issue and the related file activity:

• Issue created — Jan 2, 2026, 7:30 AM GMT+5:30
• File created — Jan 2, 2026, 7:34 AM GMT+5:30
• PR Added CVE-2016-15043 template #14674 submitted by @D3nverNg,@thewindghost — Jan 2, 2026, 7:42 AM GMT+5:30
• File update — Jan 2, 2026, 8:51 AM GMT+5:30
• “Validated with a vulnerable host” comment edited — Jan 2, 2026, 8:50 AM GMT+5:30
• File updated with working version / debug output — Jan 2, 2026, 9:38 AM GMT+5:30

From this sequence, it appears that the PR was created before the template was fully tested and validated, and the validation + debug output were added later after submission.

Observations

• The file was created within 5 minutes of the issue.
• The PR was opened 8 minutes later, without local validation or debug output.
• More than 1 hour later, the file was updated with correct vulnerability detection and exploit logic.
• The PR description was edited to claim validation at 8:50 AM, followed by adding debug output at 9:38 AM.

If the template was truly validated within the first few minutes, then why were the following not completed before opening the PR?

• Validation against a vulnerable host (True Positive)
• Validation against a patched host or secure configuration (to avoid False Positives)
• Debug output included as part of the initial submission

@D3nverNg , @thewindghost — it is surprising that within 4–5 minutes the vulnerability was fully understood, a lab was set up, a Nuclei template was written with correct matchers, and validation was completed—without errors and without AI.

@thewindghost It is unfair to judge before verifying why I am making this claim.

In addition, similar submission timing from @D3nverNg can be observed in other cases as well:

• Issue CVE-2018-15133 - Laravel Framework - Remote Code Execution 💰 #14598 Dec 28, 2025, 7:30 AM GMT+5:30

  • PR Added CVE-2018-15133 Template #14599 Dec 28, 2025, 7:40 AM GMT+5:30

• Issue CVE-2018-6961 - VMware NSX SD-WAN Edge - Command Injection 💰 #14623 Dec 30, 2025, 7:30 AM GMT+5:30

  • PR Add CVE-2018-6961 Template #14625 Dec 30, 2025, 7:37 AM GMT+5:30

• Issue CVE-2016-15043 - WP Mobile Detector WordPress plugin - Unrestricted File Upload 💰 #14673 Jan 1, 2026, 7:30 AM GMT+5:30

  • PR Added CVE-2016-15048 template #14656 Jan 1, 2026, 7:36 AM GMT+5:30

[thewindghost]

Listen @Sourabh-Sahu,

I think there is some confusion here. This discussion is focusing heavily on timelines and assumptions, rather than on any actual rule violation or technical issue.

Making a mistake in an initial submission and correcting it later is not prohibited by any contribution guideline. Pull requests are explicitly meant to be iterated on before review. There is no requirement that validation, debug output, or finalized logic must exist at the exact moment a PR is opened.

You are framing this as a concern about fairness or potential cheating, but no concrete evidence of misconduct has been presented. If cheating is the concern, then the discussion should focus on specific technical issues such as copied code, false positives, incorrect matchers, or guideline violations not on speculation based on how fast someone works.

Regarding the edits: the PR did include multiple file updates, and an initial mistake in merging files led to the PR being closed and reposted. That was an operational error, not an attempt to misrepresent validation or results.

At this point, further debate based on assumptions is not productive. The appropriate path forward is for reviewers to evaluate the final state of the template on its technical merit.

Let's wait for the reviewers’ decision.

• Stop using AI for Reply my Comment
• Read the PRs that he himself closed and see how many files were uploaded to them; you'll understand the problem if you're capable enough.

[princechaddha]

@D3nverNg @Sourabh-Sahu @thewindghost Thank you for raising your concerns. The purpose of this reward program is to work together with the community to make the internet safer by enabling security checks for companies and individuals to scan their assets for vulnerabilities. We encourage contributors to collaborate and help strengthen this initiative.

Regarding the concerns mentioned only submissions that include a fully working template along with debug data and a vulnerable environment setup will be considered eligible for the reward. If a template PR is submitted without the required debug data and vulnerable environment needed for validation, it will not be counted as the first valid submission.

The official submission time will be based on when all required elements are successfully provided. This means the timestamp of the latest required component (valid template, debug data or vulnerable environment) will determine the submission time.
For example:

• If a PR is submitted at 10 AM,
• Debug and validation data at 5 PM, and
• The final working fix at 7 PM,
  then 7 PM will be considered the submission time for bounty evaluation.

Our goal is to keep this simple and fair, the reward timing will be based on when the submission becomes fully valid and verifiable. @projectdiscovery/template

[thewindghost]

@princechaddha Thank you so much brother!

If so, then D3nverNG's submission is still valid because it was the first with complete information, better than the other one because it includes clear -debug images with both the old and new (patched) versions. The other contributor, however, accused us of cheating, while we were only fixing a bug in the template. Despite our explanation, he didn't read it and continued searching for buggy pull requests (PRs) pushing a lot of code, serving his personal attack!

[princechaddha]

@thewindghost, let's please refrain from making such comments about any contributors going forward this applies to everyone involved. Instead let's keep our focus on positive collaboration. The team will review this PR shortly and based on the metrics outlined above, the valid submission will be rewarded accordingly. Thank you!