eMudhra exits SSL/TLS after weak intermediate CA keys and 4 more

What people are saying

Amazon says its MadPot honeypots logged a PHP2Shell exploitation attempt on October 17, four days before the flaws were disclosed (Amazon Web Services). In a Hacker News thread, one commenter used the report to attack the PHP team for criticizing Chainguard in its public announcement. A larger Hacker News thread centers on a user who said they posted about the bugs without knowing an embargo existed.

What holds up

The flaws are real and severe. The PHP Foundation released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It said the two CVE IDs began circulating on forums and social media on October 20 at around 15:00 UTC, and that no technical details leaked.

Amazon's own post is more cautious than the headlines. It says analysis is ongoing and it is unclear whether any of these attempts would have succeeded on real-world systems. It also says it is unclear how the October 17 actor got exploit information.

Others saw attempts before the fixes: SecurityWeek reports that Hadrian, Patchstack and Cloudflare saw attempts hours before release. WatchTowr told SecurityWeek the circulating exploits either do not work, test for timing differences or crash the target. Huntress had seen no in-the-wild exploitation on partner systems as of October 21 at 4:30pm ET.

Our verdict is partly confirmed. Attempts before disclosure are established, but successful compromise before the patch is not.

Inside the threads

In the Amazon thread, one camp read the post as proof Amazon sat on the bug. Others replied that Amazon likely searched old honeypot logs after the fact, which in our reading is the plainer interpretation. Practitioners said they had seen probing in logs but no working exploit. One asked reporters to state "what they actually observed" when they cite exploitation attempts. Claims that insiders sold the bug are speculation, and no source supports them. In the embargo thread, most commenters said someone outside an embargo cannot break it, and several said the early post gave them time to mitigate.

Our take

We think the October 17 date matters more as an investigation start point than as proof of a breach. A single honeypot hit from an anonymizing network tells you someone was looking, not that anyone got in. The blame fight over the embargo is overblown for a security leader, since the patch is out either way. The underrated problem is inventory. In our reading, VulnCheck counted more than a million internet-facing hosts on end-of-life (EoL) PHP versions, and those will not get official fixes. If your team cannot say within hours where PHP runs, including vendor appliances and old marketing sites, that is the gap this event exposes. A 30-day patch service level for internet-facing critical flaws now looks unrealistic.

What to do

• Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On EoL versions you cannot move yet, Huntress advises setting session.upload_progress.enabled = Off in php.ini.
• Search web logs back to October 17 for POST requests with the PHP_SESSION_UPLOAD_PROGRESS string in form uploads, as Amazon recommends.
• Investigate rather than block Amazon's listed IP addresses, because they include shared anonymization infrastructure.
• Build a list of every PHP host, including third-party and forgotten systems, and track how long that list takes to produce.

What people are saying

Security firm Calif published a short post declaring, "Today, we hacked what we'd set out to hack: the iPhone." The post was shared on Hacker News, where the discussion ranged well beyond the hack itself. As it is spreading, the claim is that a working iPhone attack chain exists and has been shown in public.

What holds up

Calif says the post covers a series of demos it revealed at Hexacon in Paris, and that everything will be released in due time. One demo involves a third-party app. The post then turns to Apple's own messaging service, asking who cares about a third-party app when everyone uses iMessage.

Another demo is captioned with a play on APT, the usual shorthand for advanced persistent threat. In our reading, that caption hints at an attack that survives on the device, but Calif has not spelled that out.

Calif says the technical material will come later. Until then, the specific bugs, the affected iOS versions, Apple's response and the patch status are not established. Every claim comes from the firm that made it, so our verdict is unconfirmed. Presenting at a known security conference makes the claim credible to us. Credible is not the same as verified.

Inside the threads

Much of the thread became an old argument about jailbreaking. One commenter said Apple can detect a jailbroken phone and lock it out of iCloud and iMessage. Another replied that they want Apple to "lock down my iPhone as much as possible" given the threat volume. A third camp argued that closed platforms win because hobbyist projects do not design good products.

A separate strand assumed artificial intelligence (AI) models were behind the finds. One commenter complained that frontier labs keep red-team model access for insiders, and another pointed to Chinese open-source models. Calif did not make that link. It is the commenters' framing.

Our take

We would treat this as likely real but not yet actionable in detail. In our reading, if it is confirmed, a one-click attack through a messaging app plus an iMessage demo is the capability that commercial spyware buyers pay for.

The exposure is concentrated in executives, legal and finance staff, and anyone whose access is worth a targeted operation. It is not spread evenly across the fleet.

The jailbreak and AI debates are noise for a security leader. The underrated risk is the gap after Calif releases details. Enterprise iOS fleets often lag on updates, and that lag is where public research becomes usable by others.

A persistence claim, if it holds, also matters for incident response. Mobile response playbooks that assume a reboot or a basic reset clears a compromise may need a second look.

What to do

• Use mobile device management (MDM) to enforce a minimum iOS version and shorten update grace periods, so Apple's fix reaches devices within days.
• Offer Apple's Lockdown Mode to executives and staff at high risk of targeted attacks, and brief them on what it limits.
• Review whether your mobile incident response plan covers a suspected compromise of an executive's phone, including replacing the device.

What people are saying

The Electronic Frontier Foundation (EFF) says Bill C-22, also called the Lawful Access Act, has passed the House of Commons and is now before the Canadian Senate. EFF also says the bill lets the Minister of Public Safety order companies to create a backdoor for law enforcement, as long as it does not lead to systemic insecurity.

In a Hacker News thread, one commenter said a petition to withdraw and amend the bill was presented to the House of Commons. Replies to EFF's Mastodon post compared Canada to Saudi Arabia.

What holds up

The law firm Norton Rose Fulbright confirms the bill passed third reading in the House and awaits Senate consideration. The firm says the bill creates a compliance framework that requires service providers to develop and maintain technical capabilities to respond to authorized access requests.

The retention period differs between accounts. EFF says services must retain metadata for up to a year. Law professor Michael Geist describes a retention period of up to six months.

Part 2, the capability and retention regime, takes effect on a date fixed by Cabinet order. Officials told Senator Denise Batters, the bill's critic, that the first phase of regulations would probably take 18 months to two years after Royal Assent. Geist adds that section 14 bars providers from disclosing those orders except as the Act permits.

On September 24, 2026, Chamber of Progress and 22 other companies and organizations wrote to the Minister of Public Safety. The letter warns that even non-core providers could face secret ministerial orders to build surveillance capabilities. It also says some firms have said they will leave Canada if the bill passes unchanged.

The verdict is partly confirmed. The Senate stage and the capability mandate are established. The petition and the scale of any company exits are not.

Inside the threads

One camp on Hacker News said it is very rare for the Senate to kill a bill. A commenter in that camp said the realistic hope is amendments that curtail the worst parts. Another camp predicted that major messaging services would block Canada, while others expected companies to wait and doubted the bill would trigger anything immediate. A commenter who said they had read the bill pointed out that it contains no restriction on compelling real-time wiretaps. One commenter claimed the government is already working with companies to prepare data-handover infrastructure, and offered nothing to support it.

Our take

We think the backdoor framing draws the clicks, but the secret ministerial order is the harder problem for a security leader. In our reading, an order you cannot disclose collides with customer contracts, audit attestations and board reporting. We think predictions of an immediate mass exit are overblown, because Part 2 waits on a Cabinet order and on regulations. The underrated risk, in our view, is retained metadata becoming a high-value target that your team must defend. Scope is the open question: until the core provider classes are set, any company serving Canadians should assume it may be covered.

What to do

• Ask counsel how a non-disclosable order would interact with your disclosure duties; our disclosure rules guide covers the U.S. side.
• Estimate the cost and breach exposure of storing metadata you do not collect today.
• Track Senate amendments before committing to product or architecture changes.

What people are saying

Phoronix reported that several new Linux kernel vulnerability reports were posted overnight to the public Linux Kernel Mailing List (LKML) rather than the private security list. Slashdot picked it up, attributing the reports to Trend Micro's Zero Day Initiative (ZDI). The argument on Hacker News quickly turned to whether the posting was a mistake at all.

What holds up

The mailing list archive is the primary record. Its header copies the public kernel list. It was sent on 21 October 2026.

The test kernel was built with the SMB Direct server and software remote direct memory access (RDMA) options enabled.

Phoronix said the vulnerabilities have yet to be patched on mainline, though some have patches in testing or queued in "-next" branches. A second 9.0 issue, ZDI-CAN-33774, is a KSMBD race condition that can lead to remote code execution. The rest include local privilege escalation bugs in the VMware graphics driver and in a search-domain TCP query path. For ZDI-CAN-33549, a patch sits in a branch intended for Linux 7.5. For the skb_zerocopy bug, kernel developers had already received a report from another source last week.

Phoronix itself hedges on intent, saying the posting seemingly was a mistake and citing replies from Greg Kroah-Hartman asking about the public submission. The postings are established. The accident framing and the idea of a trend are not, so we rate this partly confirmed.

Inside the threads

The largest camp questioned the accident story. One commenter asked whether the kernel now encourages public reporting of AI-found bugs, and another quoted kernel documentation saying such a bug means "you must treat it as public." A third argued that a bug found by a large language model (LLM) should be assumed findable by others. One commenter suggested ZDI's security priorities simply differ from the kernel's. Practitioners noted the most severe issues likely matter only where in-kernel SMB runs, and several wanted SMB out of the kernel entirely. A claim that AI companies staged the leak to sell products came with no evidence.

Our take

In our reading, whether this was an accident matters less than what it signals. If the AI-found-bug rule that commenters cited is applied as written, public pre-patch disclosure becomes a normal path for kernel bugs, and patch windows shrink accordingly. The two CVSS 9.0 headlines are narrower than they look: they sit in KSMBD's SMB Direct path, which in the test setup needed RDMA, and the vector rates attack complexity high. Most fleets do not run the in-kernel SMB server. We think the local privilege escalation bugs are underrated, because a VMware graphics driver flaw reaches far more virtual machines than KSMBD does. Treat the whole batch as public and assume exploit work has started.

What to do

• Find hosts with the ksmbd module loaded or the SMB server built in, and disable it or block SMB Direct where it is not needed.
• Track your distribution's advisories for these ZDI-CAN identifiers and plan an expedited kernel update rather than waiting for the normal cycle.
• Prioritize kernel fixes on VMware guests and tighten local shell access in the meantime.
• Ask your Linux suppliers how they handle kernel bugs disclosed publicly before a fix ships.