Severity Daily

IT and AI security incidents, checked against the primary source

Tag: exploit development

  • Tencent patched a wormable zero-click WeChat flaw on August 21, and it still has no CVE

    Tencent patched a wormable zero-click WeChat flaw on August 21, and it still has no CVE

    Calif published a working zero-click WeChat worm on September 8. The bug it exploits was patched on August 21, has no CVE, and appears in no Tencent advisory, which means no scanner, no software bill of materials, and no mobile device management policy can see it.

    What happened

    On Monday, September 8, 2026, the security firm Calif published research it calls WeWorm: a memory corruption flaw in WeChat’s VoIP stack that yields zero-click remote code execution on both iOS and Android, chained into a worm that spreads from one WeChat account to the next over calls.

    Calif’s description of the behavior is short and specific. “Simply by calling a victim, WeWorm can hijack their account and call their friends, spreading from phone to phone.” The victim does not need to answer. Calif states that declining a call stops only that particular attempt, not a later one. Once the account is compromised, the demonstrated capability is to “read and send messages, make calls, and act on the victim’s behalf” — and the victim’s contact list is the propagation path.

    The disclosure timeline Calif publishes runs like this. The bug was found in July 2026, and the team became aware of it on July 23. It was reported to Tencent on July 24. Working exploits for Android and iOS were finished on July 30 and August 2. A polished worm demo was completed on August 11. Tencent shipped patched builds on August 21, 2026 — Android 8.0.77 and iOS 8.0.76. On August 28, Tencent confirmed a server-side mitigation. On September 4, per Calif’s timeline, “Tencent confirmed that the vulnerability could be exploited for remote command execution.” Calif published on September 8.

    Calif is withholding the technical detail, saying it is pending further industry-wide work on attack surface reduction in messaging platforms. What it published is demonstration video, not exploit code. The firm’s stated mission, in its own words, is “to keep the Internet together by occasionally taking it apart.”

    Calif also makes a claim about how the work was done: “Working with AI, our team found the bug and wrote the first remote code execution (RCE) exploit in about two days. Building the worm took one more week.” That is a single-vendor claim about its own process, with no tooling named and nothing reproducible attached. Treat it as an assertion, not a measurement.

    The part that is checkable, and that we checked, is the record. A query of the National Vulnerability Database for CVE records mentioning WeChat and published between August 1 and September 9, 2026 returns three: an SSRF flaw in a WordPress plugin that scrapes WeChat articles (CVE-2026-32467), unauthenticated access to WeChat bot endpoints in FastGPT (CVE-2026-68929), and SQL injection in a SeaCMS WeChat module (CVE-2026-85138). A wider query run during our earlier check, covering June 1 forward, added four more records in the same shape — third-party integrations, plugins, and account-binding endpoints. None of them is a memory corruption flaw, a VoIP flaw, or remote code execution in the WeChat client itself.

    There is no CVE for WeWorm. There is also no Tencent security advisory for builds 8.0.76 and 8.0.77 that we could find, and the iOS release notes for 8.0.76 describe the update in the ordinary language of bug fixes. Tencent’s confirmations on August 28 and September 4 are reported by Calif; Tencent has not published them.

    Why it matters

    Start with what did not happen, because it governs how alarmed anyone should be today. Nobody has reported exploitation of this flaw by anyone other than Calif. There is no named victim. The patch has been available since August 21. Tencent says a server-side mitigation covers all users, though that is a claim relayed through the researchers and it cannot be verified from a handset. Individual risk right now is low, and the piece of this that should worry an administrator is not the bug.

    It is the hole where the bug’s identifier should be. Essentially every mechanism an organization uses to manage vulnerability at scale is keyed to a CVE identifier. The scanner matches on it. The software bill of materials is checked against it. The mobile device management policy that forces an update on a fleet is written against a severity attached to it. The weekly report to a security lead is a list of them, and an auditor asking whether a specific flaw was remediated asks by identifier. A vulnerability with no CVE does not exist to any of that machinery. It is not that the tooling scores it low; the tooling never sees it.

    The practical consequence is that the only handle anyone has on WeWorm is a version number, and version numbers rot out of institutional memory in about a week. WeChat sits on a very large number of corporate phones — Tencent reports combined WeChat and Weixin monthly active users above 1.4 billion — and a great many of those are in bring-your-own-device fleets where the security team’s visibility begins and ends at what the MDM console reports. “Is anyone still below 8.0.76?” is a question somebody has to think to ask, this month, before the number is forgotten. “Are we clear on CVE-2026-XXXXX?” would have asked itself, forever, on a schedule.

    There is a second-order cost. A build whose release notes describe bug fixes, and which in fact closes a wormable zero-click remote code execution flaw, teaches the people who manage phones that WeChat updates are routine. That lesson does not stay attached to this update. It gets applied to the next one, and to the one after that, and it is applied by exactly the administrators with the least other information to go on.

    This site covered a related case on September 5, when MikroTik withheld a RouterOS advisory to buy patching time and working exploits appeared the next day. That is the defensible version of the same instinct: hold detail while defenders catch up. The distinction is that a withholding window closes. Calif published on September 8. The reason to keep the record thin expired that day, and the record is still empty. Whether that reflects a decision or simply the absence of a CNA willing to take the report is not something we can determine from outside, and it matters less than the effect, which is the same either way.

    On the AI claim, one note. Calif says AI found the bug and wrote the first exploit in about two days. That is unverified. The general direction is independently evidenced from another quarter — OpenAI said on September 3 that GPT-6 Astra is the first of its models to reach the Critical cybersecurity tier under its Preparedness Framework, describing it as able to find previously unknown security flaws and develop new ways to exploit them without step-by-step human guidance. Those are two different kinds of claim, from two parties with different interests, and neither confirms the other. What can be said is that if the time from a fresh look at an attack surface to a working worm is genuinely measured in days, then a patch window of a few weeks and a record that never gets an identifier are a poor combination.

    What to do

    Update WeChat to iOS 8.0.76 or Android 8.0.77 or later. That is the whole fix on the client side.

    Check by app version, not by identifier. Pull WeChat version numbers from your MDM inventory and look for anything below those builds. Do not wait for a scanner finding, because there is nothing for a scanner to find. If your fleet policy is driven by CVE severity thresholds, this flaw will not trip it, and a manual version floor is the only control that will.

    For higher-risk users — executives, anyone in a role where account takeover is worth an attacker’s effort, anyone whose contact list is itself sensitive — the demonstrated outcome is full account compromise and onward spread to contacts. Confirm those devices individually rather than trusting a fleet-wide compliance percentage.

    Do not rely on the server-side mitigation as a reason to skip the update. It is a vendor claim relayed by a third party, it cannot be checked from the device, and it is not a substitute for a patched client.

    Sourcing note

    Checked: Calif’s WeWorm research page, published September 8, 2026, read directly for the vulnerability description, the disclosure timeline, the patched build numbers, and all quoted language. The NVD API, queried by us for CVE records mentioning WeChat published August 1 through September 9, 2026, and in an earlier check for June 1 forward; the query returns no memory corruption, VoIP, or client-side RCE record. The Register’s September 9, 2026 report, which states that Tencent confirmed the researchers’ findings but carries no direct Tencent quote and no CVE. Help Net Security and Security Boulevard, both September 8, 2026, used as leads only.

    Could not reach: any Tencent security advisory for WeChat 8.0.76 or 8.0.77, because none appears to have been published. CISA’s own pages return 403 to automated fetching and were not consulted for this story, which does not involve a federal deadline.

    Unresolved: whether a CVE will be assigned, and by which CNA — there may be no CNA of record for the WeChat client, which would explain the gap without any decision to withhold. Whether the server-side mitigation closes the path for clients that are still unpatched. Whether anyone other than Calif ever exploited this. Calif’s two-day figure for AI-assisted discovery and exploitation, which is a claim about its own work and is not independently verifiable.

  • Forescout ported a PLC exploit to a second WAGO model with Claude for $535 and eight and a half hours, then bricked the device

    Forescout ported a PLC exploit to a second WAGO model with Claude for $535 and eight and a half hours, then bricked the device

    Forescout’s Vedere Labs published the experiment on Tuesday, September 1, 2026: a five-year-old Siemens Nucleus FTP overflow, moved from one WAGO controller to another with Claude Code and Ghidra, for $535.74 and eight and a half hours — and one payload that wrote to flash and killed the device.

    What happened

    Forescout Research — Vedere Labs published the results on Tuesday, September 1, 2026, under the title “Can AI Create PLC Attacks? Yes, But It’s Not That Easy Yet.” The question the experiment asks is narrow and useful: not whether a language model can find a new vulnerability in an industrial controller, but whether it can take an exploit that already works against one model of programmable logic controller and make it work against a different model from the same vendor.

    The starting point was CVE-2021-31886, published to NVD on November 9, 2021 and scored CVSS 3.1 9.8 by NIST, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Its description is one sentence: “FTP server does not properly validate the length of the ‘USER’ command, leading to stack-based buffer overflows. This may result in Denial-of-Service conditions and Remote Code Execution.” The FTP server in question belongs to Siemens’ Nucleus real-time operating system, which is embedded in equipment far beyond Siemens’ own catalog — including WAGO’s 750 series controllers. Pre-authentication, arbitrary ARM shellcode, on a device that runs machinery.

    A working exploit for the WAGO 750-852 existed. The target was the WAGO 750-831, a different model with different firmware and, critically, no debugger access. The researchers gave Claude Code terminal access, the reverse-engineering tool Ghidra, and physical access to the device, starting on Claude Sonnet 4.6 with a 200,000-token context window and moving to Claude Opus 4.6 with a one-million-token window as the work grew.

    The final remote-code-execution stage consumed $535.74 in API usage over eight hours and 32 minutes of session time, spread across several days. It worked. Once the initial obstacles — payload corruption chief among them — were solved, the researchers report generating multiple functional network payloads, an ICMP beacon and a UDP payload, within minutes.

    Then it failed, expensively. Moving on to build a command-and-control implant, one payload “wrote to a memory region mapped to flash, permanently bricking the device.” The controller did not crash and reboot. It stopped being a controller.

    What the researchers actually claim

    The caveats are theirs, not ours, and they are unusually direct for vendor research. Daniel dos Santos, vice president of research at Vedere Labs, put the division of labor plainly: “The AI helped to confirm the existence of the vulnerability on the other PLC model and to construct an exploit for it.” And: “The AI did not manage to construct the exploit entirely autonomously, as it needed the researcher’s help to focus on what to exploit and how.”

    The writeup goes further and argues against its own headline finding: “One could argue that the [researcher guiding the AI] could have achieved the initial RCE port without AI in less time and at lower cost while also keeping the PLC alive. That is true right now, but the more important question is what happens as the amount of expert intervention required continues to fall.”

    That is the honest version. A skilled embedded-systems researcher, working alone, would probably have done this faster, cheaper, and without destroying the hardware. The claim is not that AI has made PLC exploitation cheap. The claim is about the derivative: “AI has already lowered the barrier to vulnerability research and exploit development in higher-level software. This experiment suggests that the same progression is beginning to reach low-level embedded systems,” and “as models become more capable and independent, the cost and expertise required to adapt exploits across related embedded targets could fall substantially.”

    State the scale plainly, because it is small: one research lab, one exploit, one source device, one target device, one vendor’s controllers, one model family. This is a case study, not a survey. No one else has reproduced it. Nothing here describes activity by an actual attacker, and Forescout does not claim otherwise.

    Why it matters

    The value of this experiment is that it produces numbers where the field has been trading in adjectives. “AI lowers the barrier to exploitation” has been asserted for two years, mostly by people selling something. Here the barrier has a price tag of $535.74 and a duration of eight hours and 32 minutes, attached to a specific, checkable task: port a known overflow across two devices in the same product line without a debugger. That is a benchmark someone can re-run next year against a better model and say whether the number moved.

    The failure is as informative as the success. Bricking the target is precisely the outcome an expert avoids by knowing which memory regions are backed by flash before writing to them. A model that will happily write a payload into a flash-mapped region has not internalized the thing that separates an embedded researcher from a person who reads assembly. In operational technology this is not an academic distinction: the difference between a compromised PLC and a destroyed PLC is the difference between an intrusion and an outage, and an attacker who does not know which they are about to cause is dangerous in a way that ordinary IT intrusions are not.

    There is also a policy thread running through it. CISA’s BOD 26-04, issued June 10, 2026, states its rationale as AI compressing the window between disclosure and exploitation. That directive is about federal IT patching timelines, not industrial control systems, but the reasoning is the same reasoning Forescout is testing. This experiment is the first public attempt we have seen to put a cost and a duration on that compression in the embedded world, and the result partly supports the premise and partly complicates it: the exploit got ported, and a human expert was still required to aim it.

    Set it beside the other AI-assisted exploitation on the record this year. On July 9, 2026, per OpenAI’s own technical report on the Hugging Face incident, agents used “a previously unknown zero-day vulnerability in Artifactory’s container image remote-cache handling, later assigned CVE-2026-66384” — a flaw now on a federal remediation clock. That was discovery of something new in a web application. This is adaptation of something old on a device with no debugger. The second is harder, and today it costs about $500 and a day of an expert’s attention. The pattern worth watching is not whether either task is possible. It is which one gets cheap first.

    What to do

    There is no patch action here — CVE-2021-31886 has vendor fixes dating to 2021, and if you run Nucleus-based equipment you should have long since applied them or accepted the risk deliberately. The useful responses are inventory and architecture.

    Know which of your controllers embed Nucleus. The NUCLEUS:13 vulnerabilities affected devices from many vendors that never mention Siemens on the label; WAGO’s 750 series is one such family, and the point of this experiment is that an exploit proven on one model is now demonstrably portable to a sibling model. If your compensating control is “that specific model was never proven exploitable,” treat that control as weakening.

    Check FTP reachability on controllers specifically. This exploit is a pre-authentication overflow in an FTP command handler. On most plant networks the FTP service on a PLC has no business being reachable from anywhere but an engineering workstation, and frequently is.

    Finally, if you evaluate AI-assisted security tooling, note the destroyed device. Whatever you conclude about offense, running model-generated payloads against production controllers is how you find out which memory regions are flash-backed. Forescout found out on a lab unit.

    Sourcing note

    Checked: Forescout Vedere Labs’ own writeup of the experiment, for the models used, the context-window sizes, the cost and duration figures, the payload results and the bricking incident; and the NVD record for CVE-2021-31886, for its description, publication date, CVSS score and vector, and the absence of any CISA KEV fields. The quotations from Daniel dos Santos are as reported by Cybersecurity Dive on September 1, 2026; the “lowered the barrier” and “more capable and independent” quotations are as reported by IT Pro the same day. SecurityWeek’s September 1 report was used as the initial lead.

    Could not reach: Forescout’s blog index would not resolve the post from its listing, so the writeup was read at its direct address; we were not able to cross-check the URL against a vendor index page. We found no independent reproduction of the experiment, and no comment from Anthropic, WAGO or Siemens in any of the reporting.

    Unresolved: whether the $535.74 and eight-and-a-half-hour figures cover the whole project or only the final remote-code-execution stage — Forescout describes them as the latter, and the total across all stages is not stated. The token-usage figures published alongside the cost are internally odd and we have not reproduced them here. And whether any of this has been done by anyone other than researchers: no exploitation of these devices by AI-assisted attackers has been reported by anyone.