Leak hit HN 2026-10-20 15:20Z. PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 fix both CVEs.

Mechanism: php_request_startup() calls php_hash_environment() (multipart parse, the session.upload_progress callback, php_session_initialize() on the process-wide BG(serialize)/BG(unserialize)) one line before zend_activate_modules() runs basic's RINIT, which is what zeroes them.

CVE-2026-109618 is the exit direction: an OOM longjmp out of the serializer leaves partial state and mod_php runs shutdown anyway.

CVE-2026-109619 is the entry direction: the next request on the same worker dereferences that state before RINIT.

The 8.5.12 patch adds php_basic_early_rinit(), a PS(in_rfc1867_update) flag that forces incomplete_classes_only inside the window, and removes zend_bailout() from the OOM path. The ordering is unchanged.

The post_bytes_processed UAF theory behind most of the 70+ GitHub repos does not fire: the cached array's refcount walks 2 to 1 and never reaches 0 on instrumented 8.2.34 through 8.5.12 (xuehuolll audit, dinosn lab). Three paths survive 8.5.12: the var_destroy re-entry UAF, the serialize_handler mismatch, and upload-progress session injection.

Labs: https://github.com/dinosn/php-cve-2026-10961x-lab-poc and https://github.com/xuehuolll/php2shell-CVE-2026-109618-109619

uCreater (the vendor's own name for the product is YingGai) is a commercial Android surveillance platform built around 群控 (“mass control”). Branded through packages in the com.ucreator.* namespace, it is not a single malware family but a productized framework: a VirtualApp/LSPatch engine, a library of per-application hook modules, a Redis and HTTP control plane, a cloud-phone farm for live screen control, and a Windows operator console. Customers can rent the platform and deploy its capabilities against different applications on a target device. Despite this breadth and multi year usage, I found little public threat reporting documenting the platform's architecture.

Author here :)

TLDR: on Oct 2, 333 exits (~10% of Tor exits) started redirecting port 22 to 12 interception servers running a paramiko-based MITM that stole passwords and tried to drop Ebury on the target.

I work at IPinfo, which runs a weekly scan of the IPv4 Internet. Short version of what we found:

• October 6–7 scan, five days before the attack: 2,528 addresses serving a Danfoss StoreView dashboard in 73 countries and territories. France had 1,331 (53%).
• 85% of the French ones ran software with known flaws, including 527 end-of-life AK-SM 800 units. Only 195 had every fix. Elsewhere it was 84%, so France had more of them online, not worse patching.
• 1,019 of the French addresses were already open on March 30.
• October 14 scan: 316 still online in France (−76%, against a normal 3–7% weekly loss). Fully patched units dropped too (195 → 54), which points to disconnection rather than patching.

Method: the newer UI is matched on page title, the older AK-SM 800 on its web server plus the Flash loader page, and firmware generation comes from the build date the dashboard exposes. Counts are addresses on the ports we scan, so they’re a floor. How the attackers got in is still unknown, and exposure isn’t proof of the entry point.

I continued researching sandbox bypasses discovered in Twig by project Glasswing. This time, I focused on CVE-2026-46633, which still had no public exploits. This writeup documents my development of payloads for the CVE-2026-46633 and the corresponding SSTImap modules.

- Google's own nameserver vouched for Russian IPs as Googlebot.

- One PTR addresses AI agents directly, and it passes forward confirmation.

- The exfil payload dodges filters for spaces, parentheses and quotes, and phones home to an IP written as one decimal number.

PhantomBuffer EDR evasion uses stealth injection via SendMessage with WM_SETTEXT to effective bypass EDR (Endpoint Detection and Response).

Unlike traditional edr bypass techniques, it does not use the VirtualAllocEx and WriteProcessMemory APIs.

Author here, I work at IPinfo. some security-relevant highlights part of the post:

• The August 28 Virtualizor update attack used a forged-origin /24 inside Hetzner’s space. From what we saw, it was RPKI-valid because Hetzner’s ROA covered the /16 and allowed announcements down to /24, and no real /24 existed to compete with it.
• We also measured how common that setup is. In this case, of 855,217 RPKI-covered IPv4 routes, 138,698 (16.2%) have a ROA looser than the route announced and no more-specific route of their own filling the gap. For IPv6 it’s 20.9%. That’s roughly 18 million more-specifics someone could announce today and come out RPKI-valid and uncontested.
• Hosting providers also differ a lot: Contabo leaves 540 of 553 covered routes open, DigitalOcean 780 of 863, OVH 11.5%.
• Invalid routes are being dropped now: a typical valid route is seen by 596 vantage points, an invalid one by 2. So the remaining risk is routes that pass the check, not ones that fail it.
• There's also the fix in RFC 9319: leave maxLength unset, so a ROA only matches the block you actually announce.

Method is at the end of the post. Happy to answer questions

If you run Laravel (or anything on Symfony), read this. CVE-2026-108082: one unauthenticated GET, seconds of backend CPU, ~100 requests and the app times out. A dumb ReDoS that common config turns into a real DoS. 👀⤵️