CVE-2026-9830, a single-file check for a reported BookingPress Pro exposure

The whole assessor is one file with one dependency

The repository tree is three entries: `LICENSE`, `README.md`, and `main.py`. There is no package directory, no requirements file, no framework, and no configuration file, and the only third-party import named anywhere is `requests`. The stated requirement is Python 3.8 or later. Getting it runnable takes three commands in an isolated environment:

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install requests

For a proof of concept that ends up in someone else's incident channel, that shape is the point. One reviewer can read the whole thing, and there is no dependency tree to pin, audit, or explain. The setup reflects the same choice. `requests` is installed by name rather than from a lockfile, the virtual environment is a local `.venv` directory you activate yourself, and there is no pinned version anywhere, so two assessors who set up the tool on different days can end up with different `requests` builds. The cost of that simplicity is that nothing here is reusable infrastructure: the moment you want two targets, a saved baseline, or a scheduled re-check, you are writing that yourself.

`python3 main.py --help` is where the documentation stops

The usage section gives exactly one command, and it prints the options rather than doing anything:

python3 main.py --help

After that it says the target is supplied through the command line, that an assessor should begin with the non-invasive check mode, and that data should not be collected beyond the approved scope. It does not give a copy-and-paste invocation, and it does not name the REST route being tested. That is a boundary rather than an oversight. The scope list describes what the script does in the abstract, normalises a supplied WordPress target URL, and checks the BookingPress Pro REST endpoint for an exposed booking response, without spelling out the request an unauthorised reader would need in order to assemble one.

Five settings decide whether a run is a check or a collection

The script supports timeout, proxy, user-agent, booking ID, and date filtering. Each one changes what the run is, rather than just how it looks. Timeout bounds how long a request can hang. A proxy is what lets an assessor route the check through the agreed path when direct egress is blocked, and it is also how a retest can be repeated from the same vantage point. The user-agent setting identifies the assessor to the site being tested, which matters when the remediation guidance asks owners to review logs for unusual requests. Booking ID and date filtering are the two that narrow what comes back, and they are what let a check return a verdict without retaining the payload.

Response files are treated as personal data, not as evidence

The scope section says the script can save a returned response locally when invoked by an authorised assessor, so saving is a deliberate act rather than a side effect. The reason is spelled out in the data handling section: those JSON files may contain customer names, email addresses, telephone numbers, booking dates, and service details. Four rules follow. Store outputs only in approved encrypted locations. Limit access to authorised assessment staff. Redact personal data from tickets, reports, and demonstrations. Delete assessment artifacts according to the engagement's retention policy. The third of those is the one most often skipped, because a screenshot pasted into a ticket is still a copy of somebody's booking, and the fourth is the one that decides whether this repository stays out of scope six months later. The five categories the document names, customer names, email addresses, telephone numbers, booking dates, and service details, are also the categories your engagement letter has to cover before the first run, not after it.

The use restriction lives in prose, while the licence permits everything

The authorisation section is unambiguous. Use the project only against systems you own or are explicitly authorised to assess. Do not run it against public, third-party, or production systems without written permission. Handle any retrieved booking data as sensitive personal information. The disclaimer repeats the framing, calling the code for defensive security testing, verification, and research, and putting responsibility for unauthorised use on the person running it. The repository is licensed Apache-2.0, which is a permissive grant with no field-of-use restriction. That gap is worth naming: the restriction on use is a request in the README, not a licence term, so nothing in the licensing stops redistribution. The tree does not carry a `SECURITY.md`, a `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md`, or a `NOTICE.md`, which is unusual for a repository whose whole subject is coordinated disclosure. The practical read is that this is a disclosure artefact rather than a project with a disclosure process, so there is no stated channel for privately reporting a problem with the check itself.

Remediation is five steps written for the site owner

The guidance section addresses site owners and BookingPress administrators, not reporters. First, upgrade BookingPress Pro and WordPress to supported versions with all vendor security fixes applied. Second, and this is the one that addresses the reported exposure directly, confirm that booking-related REST routes enforce authentication and capability checks before returning customer data. Third, restrict administrative and API access using least privilege and, where appropriate, network controls. Fourth, review web and application logs for unusual requests to BookingPress REST endpoints. Fifth, rotate credentials and follow the organisation's incident-response process if exposure is suspected. Note that the third and fourth steps persist after the patch, which is the part that tends to get skipped.

Verification asks for the minimum evidence, which is a narrow ask

The last operational section tells an assessor what to do after the fix. Repeat the authorised check, and confirm that unauthenticated requests cannot return booking or customer records. Then record only the minimum evidence needed to demonstrate the fix. That last sentence is doing real work. A full before-and-after capture with payloads would be the strongest possible proof and also the largest possible copy of customer data, so the document asks for the opposite: enough to show the behaviour changed, not enough to reconstruct what leaked. It also implies running the check twice, before and after, under the same authorisation, which is a scheduling problem the repository does not solve for you. If the engagement requires more than the minimum, that is a conversation with the data owner, not something to infer from the tooling.

The repository name is the identifier, and there is no release

Naming conventions tell you what kind of artefact this is. The repository is called `CVE-2026-9830`, so the slug itself is the identifier: anyone who searches for the advisory number lands here, and there is no separate project name to learn. There is no homepage, no topics, and no GitHub releases, and the default branch is main with a last push on 2026-08-20. The repository is not archived, so the single file is still the current version of the check. The disclaimer is the last section of the README, after the remediation and verification guidance, which is roughly the order a reader needs them in.

Editorial conclusion

Use this repository the way its author framed it: as a repeatable check that an assessor can run before and after a fix, on a system they have written permission to test. It is not a scanner, not a framework, and not something to point at a list of hosts. The absence of a working invocation in the documentation is deliberate, and anyone who needs one has a use the maintainer explicitly disclaimed. If you run the site rather than the test, skip the tool and work through the five remediation steps, then confirm the fix with the same check under the same authorisation.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. opaxial/CVE-2026-9830 on GitHub
4. README