Do not publish exploitable details in a public issue, forum post or knowledge base article. Use the relevant private GitHub Security Advisory or the maintainer’s approved private channel. A useful report identifies the affected package and version, WordPress/PHP environment, prerequisites, a minimal reproduction using synthetic data, impact, attack prerequisites and a proposed mitigation. Include timestamps in UTC and enough redacted evidence to correlate the behavior without handing over a live credential.
Never attach license keys, activation tokens, payment credentials, card data, guest names or email addresses, signed confirmation links, iCal feed URLs, webhook signatures, production database dumps or raw exception payloads. Replace them with stable placeholders and state which values were redacted. If a token may have leaked, rotate it first and note the rotation time rather than sending the token.
Triage expectations
- Keep the vulnerable site away from public demonstrations while the report is assessed.
- Preserve the affected package and a clean baseline so maintainers can compare behavior.
- Do not modify booking, payment, tax or inventory rows to prove impact.
- Coordinate disclosure timing with the security owner; do not promise a fix date publicly.
For urgent active abuse, contain access and rotate secrets immediately, then submit the private report with the incident timeline. Support can route a configuration problem, but suspected authorization or secret disclosure stays with product security.