Adform: the shared tracking script every customer site embeds was trojanised with a clipboard-rewriting crypto-clipper, and no antivirus engine flagged it

Adform, an advertising-technology platform headquartered in Copenhagen, has confirmed a compromise of its platform in which, in the company's own words, the code "was designed to interfere with certain cryptocurrency transactions involving Bitcoin, Ethereum, or Tron by attempting to replace a cryptocurrency wallet address copied to a user's clipboard with a different address"; it says it detected the activity on 2026-07-27, contained the incident, removed the malicious code and reported it to the authorities (Adform, 2026-07-31). Adform's notice does not identify the affected asset. That identification comes from the reporting: independent researcher Kevin Beaumont discovered the compromise and traced it to trackpoint-async.js, Adform's JavaScript tracking script served from s2.adform.net and embedded in websites using the platform (BleepingComputer, 2026-07-31). Adform's implementation documentation allows that tag to run on one page, several sections, or unconditionally across an entire website, and compromising the shared resource is what gave the attackers a route onto unrelated downstream sites without breaching any of them individually (The Hacker News, 2026-08-01).

The captured sample carries two malicious blocks appended to the end of the legitimate library, their replacement strings obfuscated with a six-byte XOR key. The first watches for the copy event, polls the clipboard every four seconds and substitutes matching addresses; the second walks the document's text nodes, rewrites values in input, textarea and contenteditable elements, restores the cursor position afterwards, and hooks the value setter on input and textarea elements so that programmatic writes are rewritten in transit — it also intercepts copy, cut, paste and input events, so clipboard copying was never the only path to replacement (The Hacker News, 2026-08-01). Beaumont's description of the user experience is the operationally important part: "Even if you notice the address is wrong and recopy the wallet, it keeps replacing it" (The Hacker News, 2026-08-01). BleepingComputer separately analysed an archived copy and confirmed a self-executing obfuscated payload appended to the legitimate library, including a function that replaced any string matching a wallet-address format and logic that rewrote addresses displayed on the page (BleepingComputer, 2026-07-31). At the time of the researcher's report the file returned no detections on VirusTotal (The Hacker News, 2026-08-01).

Two questions are openly contested and defenders should not resolve them in Adform's favour by default. On duration, Adform's notice says the incident "may have affected individuals who visited a website using the affected Adform technology on 27 July 2026", a single day (Adform, 2026-07-31), while Beaumont says the activity had run for about the preceding week and the oldest sample BleepingComputer could locate came from an archived snapshot taken on 2026-07-26 at 23:29 GMT (BleepingComputer, 2026-07-31); The Hacker News states plainly that "The public timeline is unresolved." (The Hacker News, 2026-08-01). On data egress, Adform reports "no evidence that the malicious code transmitted users' IP addresses or information about the websites they visited to an external party" while conceding that "Technical analysis indicates that such transmission may have been possible." (Adform, 2026-07-31); the analysed sample contains a request on page load built to send the hostname and path of the page the visitor is on to an external server, though whether it reached the operator is not established by the sample alone (The Hacker News, 2026-08-01). Adform has published no indicators of compromise, has not said how the attackers reached its deployment path, and has not identified the attacker; The Hacker News notes the more useful missing figure is how many page loads actually received the altered resource, which the company has not disclosed (The Hacker News, 2026-08-01).

Detection concepts follow directly from the mechanism, and the honest starting point is that the server-side victim organisation has almost no native telemetry here — the payload executes in the visitor's browser, not on the operator's infrastructure. The vantage that would have fired is a restrictive Content-Security-Policy with a connect-src allowlist and violation reporting on any page embedding third-party tags: the injected block's outbound request to infrastructure outside the vendor's documented endpoints is a reportable violation the moment it is attempted. On managed endpoints, browser-process egress telemetry showing connections to destinations outside a tag vendor's published endpoint list while that vendor's script is loaded is the equivalent network-side signal. Triage: legitimate ad and analytics tags make outbound beacon and XHR calls constantly, so the call itself discriminates nothing — what no legitimate tracking pixel needs to do is mutate clipboard contents or rewrite the value of form input elements, and a tag script hooking copy, cut, paste and input-value setters is the behaviour that separates this from ordinary telemetry. Hardening: Subresource Integrity hashes on statically versioned third-party scripts break loudly the moment a vendor-hosted asset is modified server-side, and are worth requesting from any tag supplier that does not currently offer a pinnable, hashable asset; where SRI is not available a restrictive CSP bounds the blast radius rather than preventing the substitution itself.

CCI Nice Côte d'Azur: a compromised administrator account on the chamber's jobseeker platform was used to run the platform's own export function

The Chambre de commerce et d'industrie Nice Côte d'Azur — the public-law chamber of commerce serving businesses and project founders in the Alpes-Maritimes — has confirmed a security incident affecting its eDRH platform, which brings together candidate profiles and registered companies around employment and recruitment. On 2026-07-18, "un accès non autorisé à un compte administrateur a permis la réalisation de plusieurs exports contenant des informations sur des candidats et des entreprises" — an unauthorised party reached an account holding administrator rights and used it to generate several exports covering registered candidates and enrolled companies (Cyberattaque.org, 2026-08-01). This was not a blocked attempt — files were actually produced — and the chamber has not published the number of people affected or the total volume exported (Cyberattaque.org, 2026-08-01). A second French breach tracker reproduces the same notification (FrenchBreaches.com, 2026-07-31).

Per the notification sent to affected individuals, the fields that may have been consulted or exported are surname and first name, email address, telephone number, date of birth, professional experience and career history, education level, profile title and stated attributes, contact and notification preferences, account-creation date and last-login date (Cyberattaque.org, 2026-08-01). The chamber says it engaged technical measures with its service provider on detection to end the unauthorised access and secure the platform, and it does not say how long the account remained accessible or how many exports ran before it was blocked. Cyberattaque.org adds in its own voice — not as a statement from the chamber — that nothing disclosed supports a conclusion that the chamber's wider IT estate was compromised (Cyberattaque.org, 2026-08-01).

How the account was taken over is explicitly not stated. The relayed account lists a stolen password, a phishing campaign, credential reuse and session hijacking as the possibilities without selecting one (Cyberattaque.org, 2026-08-01) — a gap worth stating plainly rather than filling, because it is the one fact that would tell another public body which control to check first.

Detection concepts follow from what the attacker actually did after authenticating, which is the reason this is worth carrying despite the thin technical detail: no tooling was deployed and nothing was exploited on the way out. Once holding administrator rights, the intruder used the platform's own legitimate export functions to retrieve candidate and company lists. How those rights were obtained is a separate and undisclosed question — the possibilities the notification's relay lists include session hijacking, which can itself involve a software flaw, so this is not a case where the absence of a vulnerability has been established. The telemetry that catches this sits in the SaaS or hosted application's own audit log rather than in endpoint or network telemetry — administrative authentication events assessed against the account's normal geography, hours and device, followed by export or bulk-read operations assessed against that account's normal export volume and cadence. Triage: administrators of an HR or CRM platform legitimately run exports, so the export event alone discriminates nothing; the separating signals are an export by an account that has never run one, a run of exports compressed into a single session, and an export whose result-set size has no precedent for that account — and, upstream, an administrative sign-in whose source or timing breaks that account's own pattern.

CVE-2026-7849 and 19 more — Phoenix Contact CHARX SEC-3xxx EV charging controllers: unauthenticated command injection as root, unsigned firmware updates, and no fix released at disclosure

This is a recovery published by the 2026-08-02 weekly quality audit: the advisory landed inside the audit window and no entry covered it.

An advisory that lands before its own fix is unusual enough to change the defender's task from patching to containment, and this one lands with five unauthenticated CVSS 9.8 issues. The most direct is CVE-2026-7849: "Due to improper neutralization of special elements, an unauthenticated remote attacker is able to inject a command into the system configuration which is subsequently executed as root" (CERT@VDE, 2026-07-30) — no credential, no interaction, root on the controller. CVE-2026-44104 is the one with the longest tail: the basemodule firmware update process validates a "CRC32 checksum without cryptographic signature verification", and "This allows an unauthenticated remote attacker to install a modified firmware, resulting in full system compromise." A CRC32 is an accidental-corruption check, not an authenticity check, and firmware an attacker chose survives every subsequent reboot and legitimate update cycle — which is why this flaw outlives the patch for any device compromised before 1.9.1 is applied.

Two more are about services that were never meant to be reachable. CVE-2026-44101 removes authentication from the CHARX OCPP Agent, the component that speaks the Open Charge Point Protocol to the operator's backend: a remote attacker can reconfigure which backend the charge point talks to, which the advisory records as leading to denial of service and disclosure of confidential data. CVE-2026-44090 leaves the MQTT broker reachable without authentication, "protected from external access by a firewall" and nothing else. And CVE-2026-44108 undermines exactly that firewall: "Due to a flaw in the execution order of scripts during shutdown, the firewall is terminated prematurely during system shutdown. This creates a temporary window in which internal services may become externally accessible, potentially allowing an unauthenticated remote attacker to connect to these services, resulting in full system compromise." The vendor's stated mitigation is a firewall, and one of the twenty flaws is that the firewall goes away during every shutdown — so the mitigation has to be enforced by the network, not by the device.

The constituency nexus is direct rather than analogical. Public EV charging sits across two of the profiled sectors at once — energy, because charge points are grid-edge load, and transport, because municipal and fleet charging is increasingly run by cantonal and communal operators or their contractors. Phoenix Contact is a German industrial-automation supplier with a wide European installed base, and CHARX SEC controllers are the charge-point control units rather than back-office software, so the affected devices are physically distributed, frequently connected over operator or mobile networks, and rarely in a mature patch cycle. Phoenix Contact's own framing is that the "charging controllers are designed and developed for the use in closed industrial networks" — which is a statement about intended deployment, and worth checking against how they actually got deployed.

Triage: these devices produce very little telemetry, so the discriminators live on the network rather than the host. Legitimate OCPP traffic goes from the charge point to one known operator backend on a stable endpoint; a reconfiguration attack shows up as the same device suddenly establishing OCPP or WebSocket sessions to a different destination, which is a single-field comparison against an expected-backend list and needs no deep inspection. Legitimate MQTT on these units is local to the charging installation; an MQTT connection sourced from outside the charging VLAN is not a tuning question. And an unscheduled reboot followed by a firmware version that does not match the change record is the manifestation of the unsigned-update flaw — worth an inventory-diff job rather than an alert rule, since a charge point that quietly changed firmware version is the observable that matters and no log on the device will report it.

CVE-2026-48449 — Adobe Campaign Classic: an authorization flaw gives unauthenticated arbitrary code execution (CVSS 10.0), on-premise and hybrid deployments only

This is a recovery published by the 2026-08-02 weekly quality audit: the bulletin landed inside the audit window and no entry covered it.

The number that decides the timeline here is not the 10.0 but the vector. Adobe's own table gives CVE-2026-48449 as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — network reachable, low complexity, no privileges required, no user interaction, scope changed — against an Incorrect Authorization weakness (CWE-863) whose impact Adobe records as arbitrary code execution (Adobe, 2026-07-29). An authorization flaw reached without credentials on an internet-facing application is the shape that does not wait for the quarterly window, and Adobe agrees to the extent its own scale allows: it assigns priority rating 1, its most urgent. The sibling CVE-2026-48448 is a SQL injection at CVSS 8.6 with the same PR:N/UI:N prefix, impact recorded as arbitrary file-system read.

The scoping note is the part most likely to be misread in an estate inventory. Adobe states that "This security bulletin applies only to fully on-premise deployments of Adobe Campaign Classic and to the on-premise components of hybrid deployments" — Adobe-hosted instances were remediated by Adobe and need no customer action. A hybrid deployment is the trap: the hosted half is already fixed while the on-premise half is not, so an organisation whose asset register records Campaign as a SaaS product will conclude wrongly that it has nothing to do. Adobe also states it "is not aware of any exploits in the wild for any of the issues addressed in these updates", which is the correct hedge to carry — this entry is about mechanics and exposure, not about observed attacks.

What makes Campaign Classic worth the attention beyond the score is what it holds and what it touches. It is a campaign-execution platform: marketing and citizen-communication databases, subscriber lists, personal contact data, and an outbound sending capability tied to the organisation's own domain. Code execution on that host is simultaneously a personal-data exposure and a trusted-sender takeover, and public-sector bodies using it for citizen notifications inherit both.

Triage: there is no published exploitation and no proof-of-concept, so there is no attack pattern to match yet. What can be checked now is retrospective and cheap: on an ACC host that was internet-reachable while below build 9398, review the application and web-server logs for requests reaching authenticated functionality without a preceding successful authentication event, and for process creation under the ACC service account with a web-server parent — those are the generic manifestations an authorization bypass reaching code execution would produce, and their absence over the exposure window is a meaningful negative on a host with no other exposure.

CVE-2026-65766 and CVE-2026-65879 — SP Page Builder for Joomla: a CSRF token Joomla hands to anonymous visitors is the only guard on an ORDER BY injection, plus a shipped-in-source shared secret that opens a mail relay

This is a recovery published by the 2026-08-02 weekly quality audit: the disclosure landed inside the audit window and no entry covered it.

The reason CVE-2026-65766 matters is the shape of the control that was supposed to stop it. Two scores are in circulation and the discloser says which one to use: "The CNA scored the pre-authentication SQL injection 9.2 Critical. We scored it 8.7 High", and "Where the two differ, the CNA’s number is the one that travels with the CVE." (mySites.guru, 2026-07-27) — so this entry carries the CNA figures. The Dynamic Content endpoint's tag-sort feature concatenates the request's sort direction value directly into the query's ORDER BY clause — a position no prepared statement can parameterise — and the only thing in front of that endpoint is a Joomla CSRF token. Joomla issues a valid token to every visitor on page load, anonymous ones included, so an attacker's script fetches a page, lifts the token and replays it; mySites.guru states the flaw is "protected only by a CSRF token, which Joomla hands to every anonymous visitor, so it is effectively pre-auth. An attacker could read the entire database, password hashes included" (mySites.guru, 2026-07-27). The discloser confirmed it with a time-based blind proof on its own test install. A CSRF token is an anti-forgery control, not an authentication control, and any extension that treats one as an authorisation gate has the same defect class regardless of vendor.

The second flaw, CVE-2026-65879, is a design decision rather than an oversight. The ajax_contact and form_builder contact-form addons protect the configured recipient address with a signature, but as the discloser puts it, "The contact-form addons protected the recipient address with a secret that was hardcoded identically into every copy of the extension" — so the secret is public to anyone who downloads the extension, the signature is forgeable, and an attacker sets an arbitrary recipient and a spoofed sender. The outbound mail then leaves the victim's own domain and mail server, which is what makes this a deliverability and reputation problem rather than a nuisance: the spam or phishing carries the site's authenticated sending identity. Two further issues need only a low-privilege author account — an unescaped SQL injection in the media manager's search and date filters (CVE-2026-65877, CVSS 4.0 8.2), and a media-delete action that removes a request-supplied path with no traversal guard (CVE-2026-65878, CVSS 4.0 8.3), letting an author delete configuration.php or a protective .htaccess. A fifth identifier against the same versions, CVE-2026-65876, is a second unauthenticated SQL injection — through the catid parameter of the loadMoreArticles endpoint, scored CVSS 4.0 9.2 by the CNA — which the discloser explicitly did not report and did not test, but which 6.7.1 also fixes: "If you are working out what 6.7.1 actually fixed, the answer is five issues, not four."

Two things put this above the routine extension-update cycle for a public-sector estate running Joomla. First, the mechanics: an anonymous, scriptable request that returns the full user table needs no exploitation signal to force a timeline. Second, the base rate for this specific extension — mySites.guru notes it reported "the June 2026 unauthenticated icon-upload zero-day that was being exploited in the wild and fixed in 6.6.2" in the same product, and describes SP Page Builder as "one of the most widely installed page builders in the ecosystem". A product whose last unauthenticated flaw was exploited before the fix shipped does not get the benefit of the doubt on the next one.

Triage: the SQL injection produces web-server access-log entries that look entirely legitimate — a valid CSRF token, an ordinary Dynamic Content endpoint path, HTTP 200. The discriminators are in the parameter and the pattern rather than the endpoint: sort-direction values that are not asc or desc, unusually long or syntactically complex query-string values on that endpoint, and above all a long run of near-identical requests from one source with response-time variation rather than response-content variation, which is the signature of a time-based blind extraction. A single request is unremarkable; a few thousand of them against one endpoint from one address, each differing by a character, is the finding. For the mail-relay flaw, the artefact is in the mail logs rather than the web logs: messages leaving the site's mail server whose recipient domain has no relationship to the site's own audience.

COLDCARD: a preprocessor guard that tested whether a macro was defined rather than what it was set to routed key generation to a software PRNG for five years, and the keys are now being emptied

This is out of the constituency's usual nexus — a consumer Bitcoin hardware wallet, not public-sector or critical-infrastructure equipment — and is carried on two grounds: the confirmed scale of exploitation now under way (a running estimate of 1,367.05 BTC across 4,585 addresses over three waves), and a root cause that is an embedded-firmware assurance anti-pattern applying to any device whose cryptographic quality depends on a build-time switch.

In 2021 Coinkite moved COLDCARD's elliptic-curve operations onto Bitcoin Core's libsecp256k1, which required adding an embedded MicroPython library, and during that migration wallet-seed generation moved from the vendor's own ckcc.rng_bytes() to ngu.random.bytes(). That path resolved rng_get() to MicroPython's software fallback rather than COLDCARD's hardware RNG implementation (Coinkite, 2026-07-30). The reason nothing broke is the part worth reading twice: "The guard used #ifndef, which tests whether MICROPY_HW_ENABLE_RNG is defined, rather than whether its value is nonzero. We defined that macro as zero, so the #error did not stop the build." — and because the fallback provided a function with the same signature as the intended implementation, "the build completed without identifying the wrong implementation" (Coinkite, 2026-07-30). The vendor's own summary of why review missed it is the generalisable finding: "Existing review confirmed that the intended TRNG implementation was present in the firmware binary, but did not verify which rng_get() implementation the wallet seed-generation path actually reached across the two submodules." (Coinkite, 2026-07-30).

The consequence is a reduced key search space rather than a leaked key. On Mk2 and Mk3 the active PRNG was seeded primarily from device and timing state, and Coinkite estimates the effective search space at about 40 bits; Mk4, Mk5 and Q mixed in entropy from two secure elements as a backup, which it estimates leaves about 72 bits. The vendor labels both as preliminary estimates under current attack assumptions that may change as analysis continues, and states plainly that for funded wallets without either at least 50 independent private dice rolls or a strong unique passphrase, "the reduced search space is a direct security risk, not a theoretical possibility" (Coinkite, 2026-07-30). Block Engineering reached the same defect independently, framing it as a predictable RNG fallback compounded by a 32-bit reseed (Block Engineering, 2026-07-30). The affected Mk2/Mk3 firmware range is 4.0.1 through 4.1.9, corrected in 4.2.0; the other fixed builds are 5.6.0 for Mk4 and Mk5, 1.5.0Q for Q, and Edge releases 6.6.0X and 6.6.0QX. Updating does not repair a seed generated by affected firmware — those seeds must be replaced and funds migrated (Coinkite, 2026-07-30).

Exploitation is live and escalating. Galaxy Research reported a third wave on 2026-08-01 in which a further 207.7294 BTC was drained, putting its estimate of the total at 1,367.05 BTC across 4,585 addresses; it assesses waves 1 and 2 as likely one operator on shared collector addresses and identical destination-address types roughly 27 hours apart, while wave 3 used per-victim destination addresses, a different output type, batched victims and only the default derivation path — differences Galaxy says could mean either new evasion tradecraft from the same actor or a second actor exploiting the same flaw. All the attacker-controlled funds remain unspent, which Galaxy calls unusual for a theft of this size, and every compromised address was created after the vulnerable firmware shipped in March 2021 (CryptoTimes, 2026-08-01).

The discovery route is the vendor's assumption, not an established fact, and it cuts in two directions at once. Coinkite writes that because its source has always been public, "we have to assume that someone used AI to review previous versions of our firmware and stumbled upon this issue" — and in the same paragraph that "A few weeks ago, we used one of the best available AI models to review our code for security issues, and it did not find this bug or anything serious.", concluding that "Both attackers and defenders have the same AI tools, but today it did not help us, and only helped the bad guys." (Coinkite, 2026-07-30). No source establishes how the flaw was actually found.

Correction — Unit 42's autonomous-agent campaign confirmed command execution on 11 Marimo notebook endpoints as well as three NetScaler exfiltrations

UPDATE · originally covered Unit 42 recovers a live autonomous-AI attack operation after it exposed its own home directory — the confirmed compromises came from manual Citrix NetScaler exploitation (CVE-2026-3055), not the agent (2026-07-31)

the original entry understated the campaign's confirmed impact, and it did so on the strength of a quotation Unit 42 did not write. This pipeline's own weekly quality audit caught it by checking the entry's evidence[] against the fetched page.

The original entry carried, inside quotation marks and attributed to Unit 42, a sentence reading "Across all the exploitation attempts, both autonomous and manual, Unit 42 was only able to confirm three targets were successfully exploited." Unit 42's actual sentence, at the same point in the post, is "Across all the exploitation attempts, both autonomous and manual, Unit 42 confirmed data exfiltration from three Citrix NetScaler targets (CVE-2026-3055) and command execution on 11 Marimo notebook endpoints (CVE-2026-39987)" (Unit 42, 2026-07-30). The fabricated version dropped the second half of the finding and added a limiting phrase — "was only able to confirm" — that carries an editorial judgement the source does not make.

Unit 42's own CVE table is unambiguous on the omitted half: its row for CVE-2026-39987 gives the product as Marimo Notebook, the score as 9.8, the exploitation method as manual, and the status as active exploitation with command execution confirmed. The post's confirmed-impact list runs to four entries rather than one: data exfiltration from three organisations via the Citrix NetScaler flaw, command execution on 11 Marimo notebook instances, Java deserialization reverse-shell attempts against nine Apache Tomcat servers (CVE-2026-34486), and reverse-shell callbacks targeting three IKE VPN endpoints (CVE-2026-33824). Unit 42 also notes it "reviewed evidence of batch exploitation against an unknown number of hosts that were listed in a file deleted by the actor prior to our analysis", so even the enumerated figures are a floor rather than a total.

What survives from the original entry is its central reading of the autonomy question: Unit 42 attributes the confirmed compromises to the operator's manual work, and its table records the manual method against each of the four CVEs above, so the autonomous scanning component still did not itself produce the confirmed intrusions. What does not survive is the impact framing. A reader who took "three confirmed compromises, all NetScaler" from the original entry built the wrong exposure list, and the missing item is the awkward one: Marimo is an open-source reactive Python notebook that data-science and research teams install themselves, so it is far more likely to be absent from a central asset inventory than a NetScaler appliance is.

Triage: the discriminator for a notebook server is lineage rather than the process itself. A Marimo host legitimately spawns Python child processes constantly — that is what a notebook does — so process creation under the notebook service is noise. What is not noise is a child process that is not the interpreter: a shell, a download utility, or a scheduling command spawned by the notebook service account, especially on a host where no interactive session was open at that timestamp. Outbound connections from a notebook server to destinations outside the package-registry and data-source set it normally reaches are the second signal, and the two together — a non-interpreter child plus an unfamiliar egress destination within the same minute — are worth an alert on a host that was internet-reachable during the campaign window.

CVE-2026-66066 (Rails Active Storage) — the withheld attack chain is public four weeks early, and Rails has shipped forensic tooling to answer 'was I exploited?'

UPDATE · originally covered CVE-2026-66066 — Ruby on Rails Active Storage: an unauthenticated image upload reaches arbitrary file read through libvips' unfuzzed loaders, exposing every application secret (CVSS 4.0 9.5) (2026-07-31)

The disclosure timetable this entry's predecessor described has collapsed. Rails shipped the CVE-2026-66066 fixes on 2026-07-29 while deliberately withholding the exploitation mechanics — the security team "held back details about the attack vector to allow applications to be upgraded before malicious attackers could take advantage of the vulnerability" — and intended to publish them no later than 2026-08-28. On 2026-07-31 it abandoned that plan, stating that "several researchers quickly reverse-engineered the attack and have already published proofs-of-concept" (Ruby on Rails security team, 2026-07-31). The four-week grace period the prior coverage described as the defender's buffer no longer exists.

Rather than publish prose alone, the team released a repository — rails/rails-forensics-CVE-2026-66066 — containing four things a responder can use directly: a step-by-step walkthrough of the attack from the incoming request to the file being read, a guide to what evidence the attack leaves in the application database and object store, and, explicitly, what that evidence does and does not prove; plus two artifacts the team calls "agent skill"s rather than scripts, one that "works out whether your application was ever vulnerable, and if it was, over what period of time" and one that "searches your Active Storage data for the crafted files, and works out what was read if it finds any" (Ruby on Rails security team, 2026-07-31). The distinction matters operationally: these are skills intended to be driven by an AI coding agent, not standalone command-line tools. The post's author, writing as a member of the Rails security team, states the material was "extracted from work I did at 37signals to perform a forensic analysis on our own apps" — that is, it comes out of one company's real incident response rather than being written for the advisory. Nothing about the vulnerable versions or the preconditions changed: activestorage below 7.2.3.2, 8.0.5.1 and 8.1.3.1 remain affected where the application uses the libvips variant processor and accepts image uploads from untrusted users, and the fix is only effective on libvips 8.13 or newer (Ruby on Rails GHSA, 2026-07-29).

One in-window operational signal accompanies the announcement, and it should be read carefully. A maintainer of the Discourse forum platform replied in the same thread on 2026-08-01 that Discourse has "noticed an increase in this style of attack" and described the defence-in-depth work it shipped that week — moving image processing out of high-privilege processes using Linux Landlock sandboxing, with the stated design goal that an image-resizing process should be able to write to one location rather than hold write access to the whole filesystem (Discourse maintainer reply on Ruby on Rails Discussions, 2026-08-01). That observation is about the class of attack against image-processing libraries, not about CVE-2026-66066 specifically — the same reply states Discourse currently uses ImageMagick with an allowed-coder list and is only now porting to libvips, so it is not describing exploitation of this Rails flaw (Discourse maintainer reply on Ruby on Rails Discussions, 2026-08-01).

Correction — GPT5.6 did not rediscover the patched WP2Shell chain: it found the WordPress pre-auth RCE first, and the patch followed the disclosure

UPDATE · originally covered AI-accelerated exploit dev: GPT5.6 autonomously rediscovers and weaponises the WP2Shell WordPress RCE chain in ~10h for ~$25 (2026-07-21)

the original entry's framing was wrong in the direction that understates the finding, and the weekly strategic entry for W30 inherited it. The correction was found by this pipeline's own weekly quality audit re-reading the cited primary.

What Searchlight Cyber's Adam Kues actually ran was a discovery test, not a reconstruction test. The prompt handed to GPT5.6 Sol Ultra opens "This is a test of your ability to discover zero-days" and then closes off the shortcut explicitly: "Do not attempt to use changelogs, git history, or the internet to 'diff' the code against a patched version." Kues explains the reasoning in his own voice — for novel vulnerability discovery, letting a model look at change history is a waste of tokens — and adds a second guard against a failure mode he names directly: models sometimes cheat to achieve what you ask, "either by choosing extremely unlikely configuration options or by fabricating preconditions that aren’t achievable by an attacker" (Searchlight Cyber, 2026-07-20). The model was told a pre-auth-to-RCE chain existed in the repository and asked to find it from first principles, which is a directed hunt with a known-positive — but it is a hunt for something not yet public, not a rebuild of something already published.

The disclosure timeline settles it. Searchlight "held off on publishing this issue to give defenders a chance to upgrade their WordPress instances over the weekend", and during that hold two other parties independently reproduced the full chain before proof-of-concept code surfaced on GitHub. A researcher does not delay publication of a rediscovery of an already-patched bug to protect defenders; the delay only makes sense because the disclosure came first and the patch was the response to it. This pipeline's 2026-07-18 entry on the WP2Shell chain reached the same conclusion from the other direction, recording Searchlight Cyber as the discoverer of CVE-2026-63030 and CVE-2026-60137 and noting the out-of-band WordPress release of 2026-07-17 — so the store already carried the correct attribution one entry earlier and then contradicted itself three days later.

Triage: nothing here is an alertable behaviour — this is a correction to a capability assessment. The WP2Shell chain itself remains covered by this pipeline's 2026-07-18 disclosure entry and its 2026-07-26 confirmed-exploitation and KEV update, which carry the exploitation detail, the affected version boundaries and the compromise-assessment guidance; that guidance is unchanged by this correction.