Two incidents, two attack paths, and one changing security landscape

Two remote-code-execution issues dominated discussion this week:

  • wp2shell, an unauthenticated WordPress Core vulnerability chain leading to remote code execution.
  • CVE-2026-14266, a heap-based buffer overflow in 7-Zip's processing of XZ data.

Although both involve code execution, they represent very different threat models. The WordPress issue is an internet-facing, unauthenticated server-compromise path. The 7-Zip vulnerability is primarily a user-assisted endpoint initial-access opportunity.

Together, they illustrate an important point about modern offensive security: the most serious compromises increasingly come not from one catastrophic bug, but from chaining smaller trust failures across validation, caching, identity, credentials and execution boundaries.

This analysis is based on public disclosures available as of July 25, 2026. Detailed root-cause information for the 7-Zip vulnerability remains limited.

1. wp2shell: From REST API confusion to WordPress Core RCE

On July 17, 2026, WordPress released versions 6.8.6, 6.9.5 and 7.0.2 to address two security issues. WordPress 6.9 and 7.0 were affected by the complete remote-code-execution chain, while WordPress 6.8 was affected by the associated SQL injection but not the full route-confusion chain. Forced automatic updates were enabled because of the severity.

The two vulnerabilities are:

  • CVE-2026-63030: REST API batch-route confusion
  • CVE-2026-60137: SQL injection involving author__not_in in WP_Query

This combination is particularly serious because exploitation does not depend on a vulnerable plugin, theme, stolen account or administrator interaction. A vulnerable WordPress installation exposed to the internet may provide the required attack surface on its own.

Stage one: Desynchronising validation from execution

A normal WordPress REST API request broadly follows this sequence:

  1. Match the request to a route.
  2. Validate required parameters.
  3. Sanitize the parameters.
  4. Execute the permission callback.
  5. Execute the endpoint callback.

The batch API processes multiple virtual requests inside a single outer request. To improve efficiency, it separates validation and execution into different loops. Internally, WordPress maintained one array containing matched route handlers and another containing the corresponding validation results. These arrays were expected to remain aligned by index.

The vulnerability occurred when a malformed subrequest generated an error. The validation array was updated, but the handler-match array was not. Subsequent entries could therefore become misaligned:

Validation result for Route A
             ↓
Executed against Route B

An attacker could arrange for parameters to be validated according to one endpoint's schema but then passed to a different endpoint's handler. This breaks a fundamental security assumption: endpoint code often relies on the framework to guarantee that input has already been normalized and sanitized. Once that guarantee becomes unreliable, parameters that are safe under their intended type can become dangerous when passed in another form.

Stage two: Reaching the SQL injection sink

The relevant SQL construction involved WordPress's author__not_in query variable. When the value was an array, WordPress mapped each element through absint(), turning the values into integers before inserting them into the query. However, when the value was supplied as a scalar, it could reach string construction without equivalent sanitization.

Under normal conditions, the public REST parameter was required to be an array of integers, so direct exploitation should have been blocked by the endpoint's schema validation. The batch-route confusion broke that protection. It allowed an attacker-controlled scalar value to reach logic that expected validation to have already occurred, ultimately creating an SQL injection primitive.

Stage three: Recursively abusing the batch endpoint

The SQL injection was reachable through a GET-style route, while the batch API imposed restrictions on GET requests. Instead of treating that restriction as a dead end, the exploit chain recursively invoked the batch endpoint. The route-confusion issue was used once to bypass method validation and again to bypass validation of the author-exclusion parameter.

The result was an unauthenticated, UNION-capable SQL injection that could fabricate data shaped like WordPress post records. At this point the vulnerability was already severe, but database read access alone did not automatically provide administrator control. WordPress stores password hashes rather than plaintext credentials, and a reliable RCE path required further exploitation.

Stage four: Turning database output into in-memory objects

The most technically interesting part of wp2shell is the transition from SQL injection to application-level privilege escalation.

WordPress caches WP_Post objects during a request. If the same post is referenced multiple times, WordPress may reuse the in-memory object instead of querying the database again. The exploit used SQL injection to fabricate post-shaped rows and influence the objects WordPress placed into its cache. This transformed a read-oriented SQL injection into a form of in-request object fabrication and cache poisoning.

The chain then interacted with several WordPress subsystems: oEmbed cache entries, post-parent cycle handling, Customizer changesets, dynamic action hooks and recursive request processing. It first seeded oEmbed cache rows and then created a set of fake in-memory posts with carefully selected post types, statuses, parent relationships and content.

Stage five: Temporarily assuming administrator authority

WordPress Customizer changesets can store pending configuration changes as JSON. Each change can include a user_ididentifying the user whose authority should be applied when processing it. The fabricated changeset specified administrator user ID 1.

When WordPress applied the malicious changeset, it temporarily called logic equivalent to:

wp_set_current_user($setting_user_id);

This gave the request a temporary administrator context while the changeset was being processed. Ordinarily, that elevated context would be narrow and short-lived, so the exploit needed a way to perform a more useful operation before the user context reverted.

Stage six: Abusing dynamic hooks to replay the request

WordPress constructs some hook names dynamically from post status and post type:

Because the attacker-controlled object was fabricated in memory, its status and type did not need to represent a legitimate WordPress post. The exploit selected values that produced the hook name parse_request. Triggering parse_request restarted WordPress request parsing while the temporary administrator identity was still active.

The original batch request already included an operation to create a new administrator. It failed during the first anonymous execution, but succeeded when the request was replayed under the temporary administrator context. The attacker could then log in using the newly created account and upload a malicious plugin, resulting in code execution with the privileges of the web-server process.

Why this chain matters

wp2shell is not simply "an SQL injection plus an admin-account creation." It is a chain across several independent abstractions:

Each subsystem behaved roughly as designed when viewed independently. The compromise emerged from the interaction between them. That is precisely why attack-path testing remains necessary. Static scanning may identify the SQL construction or the array desynchronisation, but it is much less likely to model the complete path through cache semantics, post-parent correction, Customizer authorization and dynamic action dispatch.

Exploitation timeline

WordPress published its security releases on July 17. Wordfence reported exploit-shaped probing against the batch endpoint at 23:29 UTC that day and a clear SQL injection attempt approximately 13 minutes later. Independent reproductions and public proof-of-concept activity followed during July 18 to 19.

This is another reminder that "patch Tuesday" assumptions no longer apply to widely deployed internet-facing software. Once a patch is published, automated patch diffing can rapidly transform the fix into an exploit roadmap.

Defensive actions for WordPress operators

  • Upgrade immediately to 6.8.6, 6.9.5 or 7.0.2, according to the deployed branch.
  • Verify that the update actually completed across every instance.
  • Review requests to /wp-json/batch/v1 and ?rest_route=/batch/v1.
  • Investigate unexpected administrator accounts.
  • Review newly installed or modified plugins.
  • Check recently changed PHP files and web-accessible upload directories.
  • Validate WordPress Core files against known-good checksums.
  • Review database changes, authentication logs and web-server process activity.
  • Treat suspected exploitation as a potential full host compromise, not merely a WordPress account issue.

A web application firewall may reduce exploitability, but it does not prove that exploitation did not occur before the rule was deployed. Wordfence similarly emphasizes that firewall protection is not a substitute for patching or compromise assessment.

2. CVE-2026-14266: Understanding the real risk of the 7-Zip XZ vulnerability

CVE-2026-14266 is a heap-based buffer overflow in 7-Zip's processing of XZ chunked data. According to the Zero Day Initiative, specially crafted XZ-compressed content can overflow a heap-allocated buffer and potentially execute code in the context of the current 7-Zip process. Exploitation requires the victim to visit malicious content or open a malicious file. The vulnerability has a CVSS score of 7.0 and was fixed in 7-Zip 26.02.

"Remote code execution" does not always mean remote pre-authentication

The RCE label can be misleading when incidents are compared without considering their preconditions.

For wp2shell, the attacker may interact directly with an exposed WordPress server without authentication. For CVE-2026-14266, execution requires attacker-controlled XZ data to reach the vulnerable decompression code. In the scenario described by ZDI, this requires user interaction, such as opening a malicious archive or visiting content that causes the file to be processed.

Its practical attack path is therefore more likely to resemble:

The current public advisory does not disclose enough technical detail to determine exploit reliability, affected allocator conditions, required heap shaping or the impact of platform-level mitigations such as ASLR, DEP and control-flow protections.

Accordingly, defenders should avoid two opposite mistakes: assuming that every malformed archive provides reliable, one-click code execution; and dismissing the vulnerability because it requires user interaction or carries a lower CVSS score than wp2shell.

Malicious archives remain an effective initial-access mechanism because they align with normal business workflows. Employees regularly open compressed source code, invoices, support bundles, forensic exports, software packages and transferred documents.

Why endpoint inventory may be difficult

7-Zip can exist outside centrally managed software inventories. In addition to normal installations, organizations may have portable copies in user directories, bundled command-line binaries, developer toolchains, build and automation servers, file-processing services, incident-response and forensic toolkits, and third-party applications that invoke 7-Zip components.

The highest-risk deployment may therefore not be an employee's desktop installation. It could be an automated service that processes untrusted archives with elevated privileges.

Defensive actions for 7-Zip

  • Upgrade all managed installations to 7-Zip 26.02 or later.
  • Search endpoints and servers for unmanaged or portable copies.
  • Identify automation that processes externally supplied archives.
  • Avoid extracting untrusted archives in privileged contexts.
  • Use sandboxed or isolated processing for email and uploaded files.
  • Monitor archive utilities spawning shells, interpreters or unexpected child processes.
  • Apply attachment filtering and endpoint controls to archive-based delivery chains.
  • Include decompression libraries and utilities in software-composition and asset inventories.

A complete response should consider both the vulnerable software and the workflow surrounding it.

3. Cross-incident lessons for defenders

1. Validate trust boundaries, not only individual components

The WordPress exploit crossed validation, routing, database, cache and authorization boundaries. Security reviews should explicitly model what happens when assumptions from one component are invalidated by another.

2. Separate exposure, vulnerability, exploitability and compromise

These are different questions:

  • Vulnerability: Is an affected software version installed?
  • Exposure: Can an attacker reach the vulnerable functionality?
  • Exploitability: Do the required environmental conditions exist?
  • Compromise: Is there evidence that exploitation succeeded?

A scanner usually answers only the first question.

3. Treat data-processing systems as code-execution systems

Archives, document converters and media processors all handle complex attacker-controlled formats. The 7-Zip issue is a direct example: "opening a file" is really "running a parser over hostile input." Where processing involves complex formats, deserialization or dynamic loaders, data ingestion may effectively be code execution waiting for a boundary failure.

4. Monitor for the post-exploitation chain

Preventive controls will eventually fail. Detection should focus on transitions such as:

  • Web requests followed by administrator creation
  • Archive processing followed by shell execution
  • Newly created identities followed by privilege-sensitive actions
  • Utilities spawning unexpected child processes

5. Assume vulnerability weaponization will accelerate

Wordfence observed wp2shell-related probing within hours of disclosure. Automated patch diffing and exploit adaptation continue to shrink the time between patch publication and operational exploitation. Patch prioritization must therefore consider exposure and attack-path feasibility, not only CVSS scores and monthly maintenance windows.

Conclusion

This week's issues represent two different generations of security risk:

  • wp2shell demonstrates how framework-level logic errors can be chained through complex application behavior into unauthenticated server compromise.
  • CVE-2026-14266 shows how a user-assisted memory-corruption flaw in a common endpoint utility can create a practical initial-access opportunity.

The strategic lesson is not simply that organizations need to patch faster. They need to understand complete attack paths, continuously validate containment assumptions, monitor post-exploitation behavior and test whether their controls work against creative chains rather than isolated vulnerabilities.

At Dracosec Research Limited, we provide:

  • Web and API penetration testing
  • Infrastructure and internal-network assessments
  • Cloud and configuration security reviews
  • Exploitability validation
  • Attack-path analysis
  • Adversary-focused security testing

For organizations that need to determine whether a newly disclosed vulnerability is merely present, or genuinely exploitable within their environment, contact us to arrange a technical security assessment.


Contact DracoSec today to schedule your security assessment. 🛡️