On 12 August 2026, I sent WordPress.org Security a 509 KB report of findings revalidated against WordPress 7.0.4. The team had told me earlier that day that, although HackerOne was its preferred route, valid findings could be shared by email. I sent the report to that address, offered further reproduction details over an encrypted channel, and followed up when I received no acknowledgment. As of 31 October, I have found no reply to the report or my follow-up in the correspondence.
This is my documented account of what I sent, what the team said, and why silence after a voluntary security disclosure matters. The emails were with WordPress.org Security. I cannot identify which company or individual handled that inbox.
The correspondence, in order
| Date | What happened |
|---|---|
| 4 August 2026 | In a later email, I referred to a separate CDATA/RSS issue submitted through HackerOne as report 3912662. I am describing that submission here from my September follow-up, not from the HackerOne ticket itself. |
| 10 August, 14:04 | I emailed security@wordpress.org. I explained that a trial-account submission limit prevented me from sending more reports through HackerOne and asked whether I could send the additional findings by email using PGP. I mentioned the existing HackerOne report. |
| 12 August, 17:35 | WordPress.org Security replied. It preferred HackerOne, but said valid findings could be sent by email as well. This is the last reply from the team that I found in this correspondence. |
| 12 August, 20:40 | Relying on that reply, I sent the attached WordPress 7.0.4 validated report. I said that the findings had been checked on the latest release, described the overlap that might exist with my earlier HackerOne report, offered help with triage and patches, and asked for a PGP key or another secure route for additional PoCs. |
| 7 September, 11:48 | I followed up. I asked for confirmation that the 12 August report and attachment were accessible, a triage status by 14 September, and a secure way to provide more reproduction details. I found no reply to this follow-up. |
| 14–15 September | With no response documented by then, I published 27 bounded WordPress advisories on my advisory index. One example is HKV-ADV-2026-002, concerning an Interactivity API URL-binding XSS. The advisories distinguish observed behavior from conditional chains. |
| 26 October, 08:33 | I sent a new email to security@wordpress.org. I said I had a separate audit of WordPress 7.1.3 with 85+ findings, including eight that I assessed as allowing full remote takeover, and asked where to report them outside HackerOne. That email asked for a submission channel; it did not attach the new audit report or establish those counts independently. I have not found a reply as of 31 October. |
| 28 October | WordPress 7.1.4 shipped security fixes, including Contributor-level XSS through 'javascript:' URLs in Interactivity API bindings. The same release notes say the fixes were backported to 7.0.8. |
| 31 October | It has been 80 days since I sent the substantive 7.0.4 report and 77 days from that submission to the 7.1.4 release. I still do not have an acknowledgment, a finding-by-finding triage response, or an answer to my request for a channel for the newer audit. |
The August attachment was not a one-line allegation. It organized 24 standalone findings and seven attack-chain analyses, with reproduction procedures and explicit limitations. The topics included Contributor-to-privileged-user stored XSS, denial-of-service paths, server-side request forgery, CSS injection, and private-data disclosure. I also told the team that nine weaker candidates had been left out of the vendor report. The report separated tested results from conditional chains.
A harmless one-click proof of impact
The published XSS advisory originally withheld the exact post body. Since then, I reproduced a visible, local-only proof on official WordPress core builds. A default Contributor saved a pending post with an Interactivity API 'href' binding and a full-page style binding. An authenticated Administrator opened its preview and clicked the clearly labeled panel once. The browser executed the marker in the WordPress origin, then made one read-only GET of '/wp-admin/users.php': HTTP 200 in the Administrator session, versus HTTP 403 in a Contributor control. The test did not create a user, install a plugin, change privileges, read the response body, or run a server command.
The exact post body used in that benign test is below. The 'javascript:' value only changes a visible marker and checks the status of an administrator page. It sends no data to an outside address.
<!-- wp:search {"buttonUseIcon":true} /--><div data-wp-interactive="oneClickPoc" data-wp-context="{"url":"javascript:document.title='ONE_CLICK_POC_EXECUTED';var a=document.getElementById('one-click-poc-anchor');a.textContent='SUCCESS: ONE_CLICK_POC_EXECUTED; checking admin page';fetch('/wp-admin/users.php',{credentials:'same-origin'}).then(function(r){a.textContent='SUCCESS: ONE_CLICK_POC_EXECUTED; '+(r.status===200&&new URL(r.url).pathname==='/wp-admin/users.php'?'ADMIN_READ_OK':'ADMIN_READ_DENIED')}).catch(function(){a.textContent='SUCCESS: ONE_CLICK_POC_EXECUTED; ADMIN_READ_ERROR'});void(0)","style":"position:fixed;top:0;left:0;width:100vw;height:100vh;z-index:2147483647;background:#e8fff2;color:#123c2b;display:flex;align-items:center;justify-content:center;font-size:28px;font-weight:700;text-align:center;box-sizing:border-box;border:8px solid #159957"}"><a id="one-click-poc-anchor" data-wp-bind--href="context.url" data-wp-bind--style="context.style">Local security test: click once to show a harmless marker</a></div>The same local check produced an executable 'javascript:' link on 7.0.4 and 7.1.3. On 7.0.8 and 7.1.4, the binding produced no executable 'href' and the click was inert. The 7.0.4 and 7.0.8 results were repeated in Chromium, Firefox, and WebKit. These observations demonstrate a real privilege-boundary failure on the tested vulnerable builds. The observed outcome is one-click script execution in the Administrator browser. Every test post was deleted afterward.
Why the silence matters
Security researchers who report voluntarily need a working intake process. An acknowledgment, a secure way to share reproductions, and a clear triage status are modest requests. A substantive report followed by weeks of silence leaves the reporter unable to tell whether the attachment was received, whether the issues were duplicates, whether fixes are in progress, or whether users remain exposed. It also makes coordinated disclosure and fair attribution harder. I consider it unacceptable for a project of WordPress's reach to leave a voluntary reporter without even a receipt or triage status for 80 days.
I would welcome a reply that distinguishes valid findings, duplicates, nonissues, and issues already fixed. I would also welcome a secure route for the newer 7.1.3 audit. The 26 October email announced that audit and asked where to submit it; it should not be mistaken for delivery of the full 85+ finding report.
Attribution needs an evidence trail
The 7.1.4 release notes credit Luis Herranz and multiple independent reporters for the Interactivity API 'javascript:' URL issue, but do not name me in that entry. My 12 August submission predates the 28 October release by 77 days and included an Interactivity API URL-binding XSS finding. That chronology warrants a comparison of report timestamps, technical details, and triage records.
I am not claiming to know when other researchers found or submitted their findings, and I do not want to erase anyone's independent work. Multiple researchers can deserve credit for the same issue. I am asking that the original submission of each matching finding be examined and that appropriate credit be given to all independent reporters, including earlier reporters whose reports arrived through an email channel the team explicitly allowed. Without a response or an overlap review, I cannot know how my August report was handled.
My request remains simple: acknowledge the August report, give a finding-by-finding disposition, explain any overlap with later fixes and credits, and provide a secure submission channel for the newer audit. Even an unfavorable technical answer would be better than silence.
Why the SSRF report matters beyond XML-RPC
An old or often-disabled entry point is not a reason to dismiss the underlying network-boundary flaw. My DNS-rebinding SSRF advisory documents three distinct ways WordPress reached a prohibited internal HTTP listener in controlled tests. On WordPress 7.0.4, an unauthenticated pingback caused a blind internal GET when XML-RPC and pingbacks were enabled. Separately, the Contributor URL-details REST route made an internal GET and returned the benign listener's title, 'SSRF-PROOF-VULN34-INTERNAL', in its JSON response. The URL-details chain advisory describes that reflected metadata surface.
A third trigger used the oEmbed-cache action in admin-ajax.php. On a disposable WordPress 7.0.3 site, a Subscriber-authenticated request caused a blind GET to the internal listener after the same DNS validation-to-connection gap. That path did not use XML-RPC. It required a suitable URL in a post; its route-specific result was not rerun on 7.0.4. The 7.0.4 source retained the relevant flow, and the shared DNS-rebinding defect was independently confirmed on 7.0.4 through pingback and URL details.
The observed result is already consequential: a remote caller crossed a network boundary, and one route returned selected internal HTML metadata. If a reachable internal HTTP service exposes sensitive data through compatible GET responses or treats GET as an action, the same primitive can carry higher confidentiality or integrity impact. Those consequences depend on the target service and configuration. Calling a finding 'already known' should lead to a concrete duplicate reference, affected scope, patch status, and a comparison with alternate entry points—not a silent assumption that disabling XML-RPC resolves the shared HTTP-layer issue.
An open request to Automattic and WordPress.org Security
Automattic and WordPress.org Security: please reply with a reliable, secure channel for the separate WordPress 7.1.3 audit I raised on 26 October. That email said the audit contains 85+ candidate findings and asked where to submit it; the full newer report was not attached. Please tell me where and how to send the report and supporting PoCs, and who will acknowledge receipt and own triage. If Automattic does not manage the security inbox I used, please direct this request to the team that does.
Please also confirm receipt of my 12 August WordPress 7.0.4 attachment and give a finding-by-finding disposition. For findings that overlap the 28 October fixes or other submissions, compare the original technical details and submission dates. Where my August report independently identified a matching issue, please credit Aria Akhavan / Haikhavan Security alongside every other deserving independent reporter. If a finding is considered a duplicate or out of scope, a dated, technical explanation would let me understand and correct the record. I am asking for an evidence-based attribution review and a working disclosure channel.
Haikhavan busca socios piloto — regístrate para el early access.