wp2shell + HollowByte: Two Front-End Fires on Your Patch List
One is unauthenticated RCE with a live PoC, the other an 11-byte availability drain — different impact, different tempo, both landing on your edge.
The detail that turns a routine WordPress advisory into an urgent fire is the persistent-object-cache exploitation condition published alongside the CVE assignment — it widens the exploitable population beyond a narrow default config, and it ships with a working public exploit. Disclosure, mechanism, CVE, and PoC in one window is the canonical precursor to mass scanning, which follows a public PoC in hours, not days.
Your real exposure isn't the WordPress instance your team manages. It's the forgotten marketing microsite, the acquired-company blog, and the shadow campaign page nobody has touched since launch. wp2shell is unauthenticated RCE — a single crafted request yields full site and host compromise, no credential to phish first.
In parallel, OpenSSL's HollowByte is lower-impact but cheap to trigger: an 11-byte TLS request that never completes pins up to 131KB per request, unreleased until process restart on glibc. It's a DoS, not RCE, but it hits every TLS terminator you run — proxies, load balancers, API gateways, embedded services.
| Dimension | wp2shell | HollowByte |
|---|---|---|
| Impact | Unauthenticated RCE | Memory-exhaustion DoS |
| Trigger | Single crafted request | 11 bytes, handshake never completes |
| Exploit maturity | Public PoC + CVE | Behavior characterized (tested on glibc) |
| Patch | Available | Available |
| Urgency | Critical | High |
The two demand different tempos: WordPress is an immediate close with core patches and WAF virtual patches against published PoC signatures; OpenSSL is a sweep of your TLS front-ends backed by handshake rate-limiting and aggressive timeouts on incomplete handshakes.
One sourcing caveat before escalating to leadership: both codenames reach us through a single newsletter with no vendor advisory cited. Validate the CVE assignments, affected versions, and patch availability against the WordPress core and OpenSSL project advisories directly before treating these specifics as confirmed.
What to do
Inventory every WordPress instance — including marketing, acquired, and shadow sites — and apply the wp2shell core patch promptly; where patching lags, deploy a WAF virtual patch against the published PoC signatures and audit persistent-object-cache configs.
Sweep all OpenSSL-linked TLS terminators (proxies, LBs, API gateways, embedded services) for the HollowByte patch this sprint and add rate-limiting plus timeouts on incomplete handshakes as compensating control.