PHP2Shell flaws confirmed exploited, added to KEV and 4 more

What people are saying

A BleepingComputer report says the two PHP2Shell remote code execution (RCE) flaws, CVE-2026-109618 and CVE-2026-109619, have been successfully exploited in the wild. Before this, the same report says, attacker activity was limited to scanning, fingerprinting and non-working exploits, with no known compromises.

The story drew a discussion on r/cybersecurity. Defenders also passed around a Velociraptor detection artifact that runs a YARA scan of web server, PHP, container, web application firewall (WAF) and system logs.

What holds up

The core claim holds. The Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-109618 to its Known Exploited Vulnerabilities (KEV) catalog on October 26, with a due date of October 29. Its PHP alert says both CVEs were added that day. The National Vulnerability Database scores CVE-2026-109618 at 9.8, critical.

The report rests on honeypots that recorded confirmed RCE against an Apache mod_php installation running PHP 8.4.26. The researcher behind them said the result does not measure reliability on other worker counts, PHP builds or applications.

Other questions are still open. watchTowr says no attribution has been made public, and CISA lists known ransomware campaign use as unknown. Our verdict is confirmed.

Inside the threads

The main argument on Reddit was over whether a compromised honeypot counts as exploitation in the wild. Skeptics kept returning to the report's "intentionally favorable single-worker mod_php profile" caveat. Others answered that an unknown actor popping an exposed system is exactly what in the wild means.

One commenter, citing SecurityWeek, said the honeypots logged 35 successful shell executions from two IP addresses. Practitioners added a patching point: updating the package does not touch PHP-FPM or Apache processes that are already running. Another commenter said the way to verify is to check the hash of the running process executable, not only its start time.

One claim is out of date. A post on X circulated saying CISA had not added the CVEs to KEV, which the catalog now contradicts.

Our take

We think the honeypot debate misses the point for defenders. Working exploit chains are now in attackers' hands, and CISA has set a federal deadline two days out.

The skeptics are right that a single-worker test bed is easier than a busy production server. In our reading, that is a reason to expect lower success rates, not a reason to wait.

The underrated risk is inventory. CISA notes PHP is often a component of other software, so exposure may sit in appliances and vendor products your team does not track as PHP. Treat any unpatched internet-facing PHP host as a candidate for hunting, not only patching.

What to do

• Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, starting with internet-facing Apache mod_php hosts. Restart every PHP worker afterward so the fix takes effect.
• Take offline any system that cannot be updated now or runs PHP 8.1 or earlier, as CISA advises, and include unsupported branches back to PHP 5 in discovery.
• Hunt web and system logs for PHP worker processes launching shells or downloading tools, using CISA's SIGMA rule or the Velociraptor artifact.
• Track CVE-2026-115560, a separate PHP RCE flaw with no patch yet, and apply PHP's interim mitigation.

What people are saying

Have I Been Pwned (HIBP) has added Germany's Alternative für Deutschland (AfD) party to its database. Its listing says a September 2026 breach exposed 345k unique email addresses. It adds that hundreds of gigabytes of emails and attachments were published online the following month, with AI-generated summaries. Replies to the HIBP announcement on Mastodon were mostly jeers at the party.

What holds up

The core event is confirmed. The AfD told Tagesschau that a hosting provider for the party was attacked in September 2026. It said parts of a few mailboxes were copied, most of them unused for years. HIBP has flagged the breach as sensitive, so it is not publicly searchable. The Register reported that HIBP confirmed the scale after the AfD formally disclosed the attack. HIBP says subsequent reporting identified the provider as the party-owned Alternita Dienstleistungs GmbH.

ZDFheute counts more than 420,000 emails and over 50,000 attachments, about 300 gigabytes in total. DW put the release at some 281 gigabytes. ZDFheute says the material includes bank statements, donation information, meeting minutes and voice messages. It also reports classified material, such as confidential ministry documents. Germany's Federal Office for Information Security (BSI) said it is in contact with the AfD.

Other points are not established. The Register says no official sources have verified the attackers' account of how the attack unfolded. That account included a claim of more than a terabyte exfiltrated. Tagesschau says it is unclear whether the published emails are authentic. The AfD has said it will not say whether the emails are genuine. One outlet reported the deadline was missed, while the AfD says it informed the regulator promptly.

Inside the threads

Most Mastodon replies celebrated the leak or mocked the party. Few discussed the breach itself. One reply asked whether HIBP was a honeypot, a suggestion the thread did not back up. Another quoted the leak site's own appeal to readers. That appeal asks them to report data protection violations, because "private data of uninvolved people does not belong online." One commenter added a timeline: the leak first appeared on another site with a torrent, days before its current domains were registered.

Our take

We think the political glee in the threads is beside the point for security leaders. The useful lesson is about dormant mailboxes. In our reading, old accounts on an in-house hosting subsidiary held years of sensitive mail that nobody was using but nobody had deleted. Captive or affiliated providers often escape the third-party scrutiny an outside vendor would get. The AI-generated summaries are underrated. They turn a raw dump into searchable, quotable claims faster than any response team can check them. The notification dispute shows how fast the regulatory clock becomes a story of its own. See our GRC guide.

What to do

• Check the domains you control in HIBP's domain search. Staff who wrote to the party may appear.
• Inventory dormant mailboxes and archives, and enforce retention and deletion rules on them.
• Bring affiliated or in-house hosting entities into third-party risk reviews.
• Warn staff in exposed groups to expect targeted phishing that uses leaked context.

What people are saying

A Lobsters thread on Apple's eMudhra support page argues that Apple revoked trust in the compromised certificate authorities (CAs) and their root for its own frameworks, but not for the certificate bundle that command-line tools use. The thread's core point is that the curl Apple ships may still accept the bad certificates. An earlier Hacker News discussion of the compromise drew 504 comments.

What holds up

The core claim is confirmed by Apple. The private keys of eight eMudhra intermediate CAs were compromised, and Apple says someone holding keys from the six TLS CAs could create certificates that appear valid for any website.

Apple also says bundled tools, including curl, git, python3, ruby, perl and openssl, check certificates against /etc/ssl/cert.pem and, for certificates chaining to a root in that file, do not check Apple's block or revocation. Apple says the file will be updated in a future macOS update. MacRumors reported that Apple has not given a release date, and that there is no evidence the keys were exploited maliciously.

The Homebrew detail is less settled. A commenter who said they maintain Homebrew said they think Homebrew's curl uses Homebrew's own CA bundle by default, contradicting an earlier commenter.

Inside the threads

The main camp on Lobsters finds it odd that Apple asks administrators to edit a file by hand rather than ship a fix. One commenter pointed to macOS's rapid security release mechanism and said the bundle is not protected by System Integrity Protection (SIP), so in their view a fast fix should be feasible. Another argued that the rapid mechanism is reserved for active, destructive exploitation. Several commenters noted that Apple labels removing the second root, AAA Certificate Services, as optional, even though Apple's page says leaving it lets tools still verify the six Sectigo cross-signed certificates. On Hacker News, a commenter said no certificates from the compromised intermediates were logged to certificate transparency (CT) before browser remediation, while another noted that CT enforcement applies "only by browsers."

Our take

We think the real story is not eMudhra but a split trust model on managed Macs. Apple's block covers Safari, Mail and apps on its frameworks, while developer tooling, scripts and build agents run on a separate file Apple has not yet updated. In our reading, the exploitation risk looks low today, but the exposure window has no end date. The underrated part is Apple's line that some apps ship their own root lists and ignore both mechanisms, which means OS-level revocation is never the full answer. Removing the AAA root has side effects, since Apple warns some unaffected sites may fail to verify, so test before wide rollout.

What to do

• Decide whether to apply Apple's documented removal of both roots through your device management tool, after testing on build and developer machines.
• Recheck the file after every macOS update, since Apple says an update can replace it until the fix ships.
• Inventory tools and runtimes on Macs that bundle their own CA lists and confirm their vendors have removed the eMudhra intermediates.

What people are saying

A bug bounty hunter says his 2025 Samsung TV runs software that gathers audio, screenshots and viewing data to sharpen ad targeting. Tom's Hardware reported that he found code in the Tizen operating system covering packet logging, audio categorization, screenshots and cross-device identification for ad tracking. The story drew a Reddit r/privacy thread, and a Bluesky post restated the claim as settled fact.

What holds up

The central findings come from one person. Tom's Hardware reported that he used OpenAI tools on the TV and that the company banned him for cyber abuse, according to an email he received.

One outside check is thin. A Hugging Face engineer found the TV opened its microphone for five seconds and then stopped, but that TV was already rooted with several settings disabled, so a stock TV may behave differently.

MLQ.ai concluded that the public posts do not establish that Samsung sent raw room audio, that microphone data caused the ads, or that the behavior applies across models. It also reported that the promised technical write-up had not been published by October 26, and that Samsung had not publicly responded to the specific allegations as of that date. MLQ.ai separately cited independent testing that found traffic consistent with Automatic Content Recognition (ACR) after opt-out on some Tizen setups, though researchers could not inspect the encrypted payloads.

Samsung's ACR support page says ACR runs only if the owner opted in, and states that Samsung does not record or watch content displayed on the TV. That page is general and does not address this researcher's findings. Verdict: unconfirmed.

Inside the threads

Most of the Reddit discussion argues about privacy principles, especially pushback on the "nothing to hide" line, rather than about the evidence. Practitioners added a useful caveat: DNS filtering only works if the TV depends on DNS lookups to phone home. Several comments folded in LG, and an X post claimed LG TVs capture microphone audio in standby, which is a separate and also unverified story.

Our take

We think the specific allegation, that the TV listens to rooms and feeds ads, is ahead of its evidence and should not drive policy yet. What is not in doubt is that smart TVs are networked computers with microphones, cameras in some models, and vendor telemetry that the owner cannot fully see. That was true before this week. Boardrooms and executive offices are where this matters. Treat conference room displays as untrusted endpoints regardless of how this story resolves.

What to do

• Inventory smart TVs and displays in meeting rooms, and move them to an isolated network segment or take them offline and drive them from a managed device.
• Disable ACR, voice assistants and viewing-information services on any connected set. Consumer Reports found that turning off ACR reduces collection but cannot stop all of it.
• Count paired soundbars and Bluetooth devices as microphones in sensitive rooms.
• Watch for the researcher's write-up and any Samsung statement before revising guidance.