AI-assisted · Human-reviewed
Security research
for WordPress.
1ShotBounty reviews WordPress plugin source code with the help of AI. Suspected issues are checked locally, documented, and reviewed by a person before submission.
From project records.
Updated manually.
01 / Published work
The research so far.
Public advisories from the project. Each record links to its CVE entry; reports awaiting disclosure remain private.
CVE-2026-90960
Unauthenticated sensitive information exposure
Bounty paidCVE-2026-102435
Unauthenticated object injection with file deletion
Bounty approvedCVE-2026-103964
Information exposure through template token injection
Awaiting proposalOutcomes reflect the project's recorded status.
How disclosure is handled ↗02 / The project
Following up on what the code suggests.
A suspicious line of code leaves plenty of questions. Which versions are affected? What access is required? Can the behavior be reproduced? Has someone already reported it?
1ShotBounty brings that follow-up work into one workflow, from source review to report preparation. The current focus is WordPress plugins and submissions to an established bounty program.
03 / The process
How a report takes shape.
Source references, test results and program requirements stay with the report throughout review.
- 01
Scope & source
Check eligibility and previous reports, then review the source. Record the areas examined and any open questions.
- 02
Local checks
Test suspected issues in disposable WordPress environments. Document the version, setup and observed behavior.
- 03
Evidence review
A separate review checks the evidence and program requirements. Missing details go back for further work.
- 04
Human submission
A person checks and submits the report. The bounty program decides validity, duplicate status and any reward.
Reproduction in local environments. Submission and communication handled by a person.
04 / Development notes
Lessons from running it.
The project is still being refined. Triage feedback and failures during development inform the next changes.
A failed read needs its own status
A failed read once caused the scheduler to report zero running jobs and start another batch. The system now distinguishes an empty result from data it could not read.
Review records need a consistent source
Decisions were stored in several places, which led to conflicting status reports. A shared reader now retrieves each decision and records its source.
Triage feedback changes the process
Some submissions have been returned as duplicates or outside the program's scope. That feedback informs eligibility checks and the review of previous reports.
Coordinated disclosure
Findings appear here after a fix is available and the advisory is public, in line with the program's disclosure terms. Reports still in triage remain private.