30/10/2026

A recruiter, a hacker and data broker you never spoke

TL;DRRecruiting tools and data brokers draw on one shared pool of contact data, and every leak from that pool hands scammers a phone number with a job title attached. I found documented cases for each link in the chain. I found no source tying a named scam wave to a named breach. "AI watermarking" in hiring turned out to mean hidden text in CVs, and nothing that traces leaks. Mint a unique alias per signup and ring recruiters back on a number you looked up yourself. Companies should treat staff phone numbers as attack surface.

A recruiter you never spoke to can hold a score on you and your mobile number. Then a broker resells the number and a criminal steals the database. A stranger rings you, pretending to be that recruiter.

Your phone number is a sales lead first and an attack surface second, and both lives run on the same data.

What AI sourcing actually does

It pulls public profiles, adds an email and a phone number, ranks people against a job, then sends the message or places the call itself. Each step has a legal fight attached.

In January 2026 two job seekers filed a proposed class action against Eightfold AI in Contra Costa County Superior Court in California. They allege it acts as a consumer reporting agency under the Fair Credit Reporting Act, scoring candidates from zero to five using data they never supplied, with no way to see or dispute it. Eightfold told Fortune it does not scrape social media and that the claims lack merit. These are allegations. I found no ruling.

The contact enrichment side already has a fine. In December 2024 the French regulator CNIL fined KASPR €240,000. Its Chrome extension revealed contact details for the LinkedIn profiles customers visited, from a database of about 160 million contacts. CNIL found it had collected data from people who had limited their visibility to connections and kept it too long. It also told people only from 2022, roughly four years after launch. That is a GDPR Article 14 failure with a price on it.

Scraping supply is a fight too. LinkedIn alleged ProAPIs ran millions of fake accounts, with access rented for up to $15,000 a month. In September 2026 a federal judge finalised a consent deal: the firms stop scraping and selling, and delete what they hold. ProAPIs says it never offered scraping tools.

The ICO audited AI recruitment tools in 2024 and made nearly 300 recommendations. It found tools gathering far more than needed and keeping it indefinitely, without candidates knowing. On the calling side, Phenom sells a voice agent that phones applicants and scores answers from 1 to 5.

What "AI watermarking" really means here

Four readings, one with solid evidence.

Hidden text in CVs. This is real. Greenhouse told the New York Times about 1% of the résumés it reviewed in early 2025 carried a trick, and ManpowerGroup said it finds hidden text in roughly 100,000 a year. A USENIX Security 2026 study of 196,682 résumés from hireEZ also found about 1%, and over 90% of those were stuffed keywords. Few were instructions to the model. Nobody measured whether it works. Counter-measures are blunt: auto-reject, or recolour the font and phone the candidate.

Detecting AI-written CVs. Google's SynthID Text is a genuine watermark, but it only flags text from models that embed it and weakens after rewriting or translation. I found no evidence recruiters check CVs for watermarks. Vendors market AI detectors, and I could not verify their accuracy.

Watermarking candidate data to trace leaks. I could not find credible sources for this practice. But I curious, does it happen???

Invisible identifiers in outreach. Tracking pixels are real. France's CNIL adopted a recommendation on 12 March 2026 saying pixels measuring opens generally need prior opt-in when the recipient never asked for the email. Cold outreach is exactly that case. I did not verify the ICO position.

Same pool, different shopfronts

The 2025 exposure shows the overlap. Researchers Bob Diachenko and nexos.ai found an open 16TB database of about 4.3 billion professional records. Contact details and work histories sat alongside enrichment metrics and Apollo IDs. It sat open from 23 to 25 November 2025. The owner was never confirmed.

Breaches I could confirm:

  • National Public Data: breached in late 2023, sold in 2024. Have I Been Pwned lists about 134 million unique emails, with phone numbers and addresses, though it flags the dataset as unverified. Reports put the haul near 2.9 billion rows. The company first said 1.3 million people, then conceded "hundreds of millions" and filed Chapter 11 on 2 October 2024.
  • DemandScience, a B2B demand-generation firm: about 122 million unique accounts, business emails and job titles, with business phone numbers per ITPro. The company blamed a decommissioned system.
  • Aura, March 2026: about 900,000 marketing contacts from a company it acquired, taken after a vishing call to an employee. ShinyHunters claimed it. Aura is not a broker, and I could not confirm a 2026 breach of a classic people-search site. Have I Been Pwned found about 90% of those emails already sat in earlier breaches.

The regulatory fix exists only in California. Californians could file with DROP from 1 January 2026, and over 600 registered brokers had to start processing requests on 1 August 2026, checking at least every 45 days. As far as I could find, the UK and EU have no equivalent single switch. You file per company.

The abuse chain

The FTC says job and employment agency scam reports tripled from 2020 to 2024, with reported losses rising from $90 million to $501 million. In the UK, as relayed from the Guardian in April 2026, Report Fraud logged more than double the recruitment-scam reports in 2024 compared with 2022, Lloyds saw a 237% rise from January to August 2025. The same coverage says scammers clone recruiter profiles and tailor messages using CV details, and AI removes the bad grammar that used to give them away.

I found no source linking a specific scam campaign to a specific broker breach. The link is structural: the same fields, the same buyers.

SOURCE Public professional profile. Name and job title.
↓
SCRAPER Fake accounts and bulk pulls, as alleged in the ProAPIs case.
↓
GATE 1 / You Unique alias and separate number per signup. Article 15 and 17 requests. DROP if Californian.
↓
ENRICHMENT VENDOR Adds email and mobile number, the KASPR model.
↓
GATE 2 / Company Vendor due diligence. Ask every recruiter where they got the data.
↓
BROKER AND BREACH Resold, then leaked. NPD, DemandScience, the open 4.3 billion database.
↓
ABUSE Spam and cold calls. Smishing and vishing. Fake recruiter offers.
↓
GATE 3 / Both Call back on a published number. Phishing-resistant MFA. Port-out PIN. Forward texts to 7726.

The same list hits staff. Google's Threat Intelligence Group described a group phoning employees as fake IT support in 2025, walking them into approving a rogue app that pulled Salesforce data. Google's own instance held business contact details. Cifas reported unauthorised SIM swaps up 1,055% in 2024, nearly 3,000 cases, and Which? found weak identity checks at some networks in April 2026.

What to do

Individuals:

  • Use a fresh email alias and, where you can, a separate number for each signup. When spam arrives, the alias names the leaker.
  • Register with TPS (CTPS for companies and some partnerships). It covers live marketing calls and criminals ignore it.
  • Forward scam texts to 7726 and report fraud at Report Fraud, which replaced Action Fraud on 4 December 2025.
  • Send an Article 15 request asking where a firm got your number, then Article 17 erasure. The ICO says firms have one calendar month. Complain to the ICO if they stall.
  • Ask your network for an extra PIN on account changes, and prefer passkeys to SMS codes.
  • Never trust an inbound recruiter call. Hang up and ring the company's published number. Anyone asking for ID or payment is hostile.

Companies:

Staff contact data is part of the attack surface. Require out-of-band verification for helpdesk resets and deploy phishing-resistant MFA. Brief people on recruiter-themed lures. Audit which agencies and enrichment tools receive employee data. Under UK GDPR, an agency sourcing candidates is usually its own controller, but read the contract. Ask for their Article 14 notice and retention period, then ask where the data came from.

What I could not confirm

No evidence of resume watermarking for leak tracing. No named scam wave tied to a named breach. The Eightfold claims are unproven. Have I Been Pwned marks the NPD data unverified, and its size varies by outlet. DemandScience phone numbers come from one outlet. The Guardian figures reached me second-hand. I found no ICO enforcement over recruitment scraping, only the audit.

Verdict

The recruiting industry treats your contact details as inventory, and inventory leaks. Regulators have started charging for it, but a fine in France does not stop a call to your mobile.

So defend like the number is already out. Make the number traceable, and make every inbound recruiter earn trust through a channel you chose.

Sources
By - No comments:

Passwords were never a delegation mechanism

TL;DRBig US banks are restricting outside AI agents, and the reporting says the hard part is that an agent using the customer's own login looks exactly like the customer. That is a delegation failure. A shared password is standing access with no scope and no expiry. A retail platform should ship scoped, revocable, read-only delegation as the sanctioned lane, and make anything that moves money need a human factor the agent cannot hold.

Passwords were never a delegation mechanism. Customers are using them as one anyway, handing the keys to a chatbot that promises to sort their finances, and the biggest banks in the US have noticed.

The part worth your attention is the admission underneath the bans. The banks apparently cannot tell who is at the keyboard.

What the banks actually said

Start with what is on the record. On JPMorgan's third-quarter earnings call on 13 October, Jamie Dimon said he did not want rogue agents, and that there could be thousands of them. A bank spokeswoman told CNBC the firm does not let third parties into accounts using customers' banking credentials, as Cybernews relays it. Outside agents can see some account data read-only. They cannot send money or pay bills.

Axios reported on 22 October that major US banks are detecting third-party agents operating inside customer accounts, some of them apparently acting without the customer's instructions. The Hacker News weekly recap of 26 October put the core difficulty plainly: the agent logs in with the user's own permission and credentials, so the problem becomes telling a human from a bot. Banks are either restricting these agents or allowing read-only access. Citi, per the IBTimes summary, bars agent logins and direct transactions but allows limited read-only access through approved open-banking providers.

Bank of America emailed customers, TechCrunch reported on 27 October, under the subject line "Protecting your finances in the AI World". The message tells people not to share online banking credentials with anyone, AI agents included, and says they are responsible for activity that results from that access. You will see this repeated as the bank voiding fraud liability. As far as I could find, no outlet I could read says that, and the bank had not commented on reimbursement. The email is a warning and settles nobody's refund rights.

IBTimes adds that none of this establishes widespread unauthorised transfers or customer losses. Treat it as a control gap spotted early.

Why a shared password is the wrong primitive

When a customer pastes a password into an agent, they grant standing access. Four properties go wrong at once.

Scope. The session can do anything the customer can, so an agent hired to read a balance can also add a payee. Time. The access lasts until the password changes. Revocation. The only off switch also locks the customer out. Identity. Every action in your logs carries the customer's name, so the agent does not exist as far as your audit trail is concerned.

This is a non-human identity problem in a consumer costume. Service accounts with standing privilege turn one compromised thing into an incident, and consumers have just rebuilt that pattern at scale.

For internal agents my answer is a separate identity per agent, just-in-time access through Opal so nothing holds production rights between tasks, and a gateway, Willow in my case, that evaluates identity, connection, action scope and risk on every call. That is how I think about it, and I would ask a retail platform to answer the same four questions about a customer's agent.

What the engineering side should build

The same four questions make a workable decision path for any request that might be an agent.

REQUEST Something acts on a customer account. Human, authorised agent or rogue bot. You do not know yet.
↓
GATE 1 / Identity A delegated agent token, or a password session? A password session gets the lowest trust and is never above read-only.
↓
GATE 2 / Connection Did the customer grant this agent in the app, and is the grant still live?
↓
GATE 3 / Action scope Reading balances is in scope. Adding a payee or moving money needs its own separate grant.
↓
GATE 4 / Risk Device, behaviour, payee age, amount. Allow, step up to a human factor, or block.

Delegation first. Let the customer pick an agent, pick read-only, pick a duration, and see and kill the grant from inside the app. Read-only by default. Money movement, if it ships at all, is a separate and narrower grant with a payee allowlist and a cap. Open banking already works on this consent model for aggregators. Agents are the same shape of problem with a more eager client.

Signals second. Password sessions driven by an agent tend to carry tells: automation-flagged browsers, datacentre addresses, machine-regular timing, no pointer movement. Score them, but never treat them as a verdict. An agent driving a real browser on the customer's own laptop passes most of that, and a password manager can trip it.

Step-up and terms

Anything that moves money, adds a payee, changes contact details or lifts a limit gets a step-up the agent cannot satisfy. That means a passkey or device-bound biometric held by the human. An SMS code the customer reads out to the agent defeats the purpose, because the agent now holds the factor too.

Axios also reported agents contacting bank call centres, so the support channel needs the same identity proof as the app. Bank of America's chief executive, Brian Moynihan, said in a 14 October CNBC interview, per IBTimes, that the bank is working with AI providers so a human authorises money leaving an account. Build to that.

Then terms. Say in plain language what a delegated agent is, what sharing a password does to the customer's position, and what you do when an agent misbehaves under a valid grant. Dimon described a liability transfer, which TFTC reads as customers carrying the loss when they authorise an outside agent. TFTC also says US rules tie liability to whether the account holder authorised a transaction, and that no federal banking regulator has yet written a rule for agents. That belongs to legal, but engineering should force the question now.

What it costs

Delegated access is a product build with a long tail: scope design, consent screens, revocation, audit views and support scripts. Customers will keep pasting passwords, because the agent works with a password today and not with your API tomorrow. Behavioural scoring produces false positives, and each one is a locked-out customer on the phone. Blocking without a sanctioned lane pushes the behaviour somewhere you can see less.

I know the shape of that bill from my own pipeline, where invisible controls meant AppSec absorbing the integration work. A consumer platform pays the same bill with a much bigger audience.

Verdict

Blocking is a stopgap. Treat a password handed to an agent as a compromise-grade event in your risk model, because the credential now lives somewhere you do not control. Ship read-only delegation as the sanctioned lane. Make money movement need a human factor the agent cannot hold. Write the liability terms before an incident writes them for you.

Sources
By - No comments:

Finding bugs got cheap

TL;DRAI made finding bugs cheap and fast. Most patch processes still run on a monthly human cycle. PHP2Shell was attacked four days before a patch existed, so the exposure window is now the thing to manage. Know what you run, shield what you cannot patch yet, hunt after you patch, and triage by reachability and exploitability instead of CVSS alone.

Finding bugs got cheap. Fixing them is still a calendar event.

PHP2Shell was found by researchers working under OpenAI's Patch the Planet programme, and OpenAI's own Codex Security team reported a Brotli decoder flaw in the same fortnight. Your patch process, meanwhile, probably still waits for the second Tuesday of the month and a change ticket. That mismatch is the story of October, and I think it matters more than any single CVE.

Discovery got cheap

Microsoft's October Patch Tuesday landed at roughly 1,400 vulnerabilities, a record. The exact figure depends on who is counting. BleepingComputer says 1,411 and leaves out 348 flaws fixed earlier in the month. Hackread says 1,413, then cites 1,409 from Action1 and a Qualys breakdown that sums to 1,377. Scope differs between trackers. The order of magnitude does not. BleepingComputer puts the surge down to Microsoft using AI platforms to hunt its own bugs.

That is cheap discovery from the defender's chair: a longer queue and the same number of people. Attackers get the same tools and no change advisory board.

The window opened before the patch

PHP2Shell is two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, both scored 9.2. They were found in August, patched on 21 October and put on CISA's Known Exploited Vulnerabilities list on 26 October with a federal deadline of the 29th. I won't retell the saga. The shape of the timeline is the point.

AUG Calif (working under OpenAI's Patch the Planet programme) and Wiz find the bugs independently. Embargo starts.
↓
16 OCT Chainguard, with an in-house AI harness, finds the same flaw independently.
↓
17 OCT Amazon's honeypots record the first exploitation attempt. No patch exists.
↓
21 OCT PHP ships fixes a day early after CVE IDs leak.
↓
24 OCT A Perplexity researcher logs 35 working shells on three honeypots.
↓
26 OCT CISA adds both CVEs to KEV. Federal deadline: 29 October.

Amazon says the first attempts came four days before the patches. AWS's CISO warned defenders not to treat the disclosure date as the earliest date of exploitation. FIRST's Art Manion makes a related argument: frontier models raise the odds of several people finding the same bug, which weakens the case for long embargoes. Two months of quiet coordination did not stop a leak.

Brotli runs the same pattern smaller. CVE-2026-111497 is a high-severity out-of-bounds write in the decoder, with a public proof of concept. Node.js shipped fixes on 21 October and Microsoft followed with out-of-band .NET updates on 25 October.

Know what you run

You cannot shorten a window on a system you have not found. Start with an inventory of everything that executes PHP and everything that links Brotli, and be honest about the second list.

A shared-library fix only reaches you when the downstream product rebuilds. Microsoft's .NET notes say self-contained and Native AOT apps must be rebuilt, because updating the shared runtime will not replace a decoder linked into your binary. PHP has a sharper edge: the fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and older branches have no official fix.

My own inference, not a reported finding: the box most likely to be forgotten is the appliance with a PHP-backed web console. Vendors that bundle a runtime patch on their own schedule, and the admin interface often sits on a management network that nobody has scanned since the install. I found no public list of affected appliances, so I will name none. Mend's guidance is to include internal tools and admin panels in the inventory, and to rank a private-network panel below an internet-facing mod_php server. Fair, as long as the panel really is private.

Buy hours, then patch, then hunt

When the patch is not available or not deployable today, shrink the exposure. Pull management interfaces off the internet and allow-list the source ranges. Put a WAF rule or virtual patch in front of the application. Restrict outbound connections from PHP processes, because the honeypot attackers tried to reach external servers and a locked egress path breaks that step.

Virtual patching has a ceiling. CrowdStrike says many public proofs of concept only crash the process until adapted to the target, so a signature built on one will miss the adapted version. It is a bridge that buys hours.

Then patch, and then go looking. Exploitation preceded the fix, so a patched host can still be a compromised host. Mend recommends reviewing logs for any system that stayed unpatched after 17 October, including outbound connections from PHP processes. CISA's BOD 26-04 implementation guidance goes further for the most urgent cases: collect evidence before applying critical patches, then analyse for unauthorised access and persistence and write a triage report. Snapshot first where you can. A patch run overwrites the evidence you now need.

Triage by risk, and count what panic costs

BOD 26-04, issued in June, dropped CVSS as the prioritisation input. It asks agencies to weigh four things: whether the asset is publicly reachable, whether the CVE is on KEV, whether an attacker can automate every step, and how much control a successful attack gives. The three-day window between the KEV listing and the 29 October deadline matches the directive's tightest tier, though the PHP2Shell coverage I read did not cite the directive by name.

Now the honest part. PHP2Shell was hard to exploit. PHP itself rates attack complexity as high. It validated code execution for the first flaw against mod_php and reports no complete FPM exploit for it. The honeypot results came from a deliberately favourable single-worker setup, and the researcher who ran it said he did not test reliability elsewhere. ReliaQuest and CrowdStrike reported no successful exploitation in customer environments. Unit 42 withdrew an AI-agent intrusion claim on 25 October because it could not tie the access to these CVEs.

Panic has a price. Government and enterprise sites took themselves offline for emergency fixes, and every urgent change spends attention the next real incident will need. Risk-based triage says yes fast to the internet-facing mod_php server and slower to the private admin panel, with a written reason for each.

My own pipeline carries a tension here. Aikido opens fix PRs for dependency flags, and Safe Chain holds new package versions for 48 hours by default. A security fix published this morning is a new version, so the hold argues against the urgency. An emergency path with a named approver has to exist before the emergency does.

Verdict

Stop measuring yourself by how fast you apply a patch after it exists. Measure the time from first plausible exploitation to your last exposed host being shielded, patched and checked. Discovery will keep getting faster, and nothing on the attacker's side waits for a maintenance window.

Build the inventory this month and write the emergency path down. Rank by reachability and exploitability, with CVSS as one input among several. The teams that do this will treat the next PHP2Shell as a bad Tuesday.

Sources
By - No comments:

44 Agents and Single Attack Platform

TL;DROctober brought reports of attackers chaining AI agents, including a 44-agent platform used against Japanese organisations and ransomware affiliates whose model waits for a human before each step. Details are thin and mostly single-vendor. Plan for machine-speed chaining against exposed edge devices, shrink the management surface, alert on behaviour sequences, and put gates in the execution path, because those never needed anyone's cooperation.

Forty-four agents on a single attack platform. That is the figure TrendAI put on CyberStrikeAI after reading files its operator left in an open directory, and The Hacker News ran it on 27 October. The same month, ransomware affiliates were caught running a framework where the model plans an intrusion and then waits for a human to say yes.

I test systems for a living as a pentest consultant, so I read these reports with one question. Offence has orchestration now. What changes for the people defending?

What was reported, and by whom

CyberStrikeAI. It is an open-source security testing platform. TrendAI says an operator used it to split an attack across 44 agents, from reconnaissance through to automated reporting. At least 19 organisations saw validation activity, at least 16 of them in Japan, with Taiwan and Hong Kong also in the frame. The activity was concentrated in October. The 44 figure rests on TrendAI's analysis alone, and as far as I could find nobody has confirmed it independently.

Phantom. SOCRadar found it on exposed servers belonging to operators working with INC and The Gentlemen affiliates: 8,257 messages across 133 sessions. The products it went after included FortiClient EMS, SimpleHelp, cPanel and VPN gateways from several vendors. SOCRadar's own label for the structure is AI-executed and human-approved.

CrowdStrike. Its 21 October post covers four previously unreported actors who left their frameworks in open directories, with cases from May to August 2026. The agents made operational decisions and ran commands, and CrowdStrike says such intrusions can often reach their objective within an hour. I checked the primary post for attribution. It names Claude Code in the setups of three actors and in one of the fourth actor's two harnesses, which makes "all four used Claude Code" slightly too neat.

North Korea. Via BankInfoSecurity and Security Affairs, CYFIRMA suspects Korean-speaking operators linked to North Korea are scanning 216 hosts for the PHP2Shell flaws from 21 compromised machines. CYFIRMA's confidence in the Lazarus link is moderate, and it concedes a criminal group without state backing fits the evidence. Nothing in those write-ups mentions AI. I include it as the human-paced control sample.

The approval step cuts both ways

Phantom is the clearest case. Each campaign opens with a victim-specific master prompt telling the model to coordinate every action with the operator. The model drafts a step. Then it stops.

TASK Operator writes a victim-specific prompt. Model must coordinate every action with them.
↓
AGENT Plans the next step and generates the command. Machine speed.
↓
GATE / HUMAN APPROVAL The model waits. This runs at the speed of one person, who may be juggling several victims. Attacker bottleneck, and the only point where the chain has a human tempo.
↓
ACTION Command runs against an exposed edge or management system. Output goes back to the agent.
↓
LOOP Next step. Back to the gate.

That gate is the attackers' bottleneck. Everything around it runs at model speed, while the approval runs at the speed of an operator. The Cloud Security Alliance note infers that the design limits the cost of model errors and lets one operator run parallel intrusions. The source does not state those motives, so that is a guess.

It may also be a detection opportunity. This is my inference and no report measured it: if a person approves each step, activity against a target should show pauses at human tempo between stages, and pauses that line up across several targets in the same hour deserve a look. Do not build detection on that alone. The CyberStrikeAI write-ups describe no human role, and CrowdStrike's post describes oversight mainly as setup and tasking. The approval step is reported in one framework, so treat it as a bonus signal.

Assume machine-speed chaining at the edge

Every chain starts with something reachable. TrendAI's researchers, as relayed by eSecurity Planet, say AI multiplies the attackers' headcount while the job is still finding easy openings. So the useful work is boring. The CSA Phantom note says to take management interfaces off the internet, allowlist the management plane by IP, and give admins separate MFA-protected accounts. Credential reuse across VPN, RMM, backup and security consoles was a large force multiplier in the Phantom material. One stolen credential should not open four doors.

Detection changes shape too. CyberStrikeAI throttled traffic per target to stay under thresholds, according to the CSA note on TrendAI's report. A per-source rate limit sees nothing. Correlate low-frequency attempts across assets and over time, and alert on sequences. A new privileged account on a management server is a maybe. The same account followed by a modified VPN connection script is a story. Both items sit on CSA's Phantom hunting list.

Red team your own pipeline with agents

The next pentest I would commission is agent-driven, under written scope, pointed at your own pipeline and its controls. One question: which control only works if the caller behaves? A chained agent skips anything that asks nicely. A wiki page, an advisory check, a pre-commit hook anyone can bypass.

In my own stack the secret scan in pre-commit is advisory, and I never call it a boundary. The CI run is the control, because it blocks merge. The package proxy sits at shell level, so the agent does not know it is there. Unsigned pull requests do not merge and there is no override. The Willow gateway can allow, block, redact or escalate to a human, which is the attackers' approval step with one difference. I choose where it fires. I log tool calls and not prompts.

These gates survive an orchestrated attacker for the same reason they survive an analyst who has never heard of OWASP. They never depended on cooperation.

What I cannot tell you

Almost all of this is vendor research built from infrastructure operators left open. SOCRadar's exploitation counts come from operator records, and CSA knew of no independent confirmation. About 62 organisations were reportedly targeted and only four appeared on leak sites, with no payment records recovered. TrendAI found no evidence that its three Japanese cases share an operator. Because this picture exists through operator mistakes, careful operators are invisible in it, which makes it a floor and not a ceiling.

Verdict

The number 44 matters less than the pause. Orchestration raises the speed and breadth of chained attempts against whatever you leave exposed, and that is an exposure, patching and detection problem you already own. Stop treating the human approval step as comfort. It is an operator's queue, and it may leave a trace.

Fix the edge, alert on sequences, and put your gates where the agent acts. Any control that needs cooperation loses to a machine that never gets tired.

Sources
By - No comments:

Nobody Attacked Anyone

TL;DRGlow Labs reported coding agents publishing more than 13,000 internal images to public GitHub while doing routine work. No attacker was involved. The agent had a task, a write path and a public destination, and that was enough. Secret scanning in CI is still mandatory, but it reads text and a screenshot is not text. Put the controls on the places an agent is allowed to write, and make them impossible to skip.

Nobody attacked anyone. An agent was asked to show a reviewer what a UI change looked like, and its command line could not attach an image to a pull request. So it put the picture somewhere public where a link would work. Task done. Ticket closed.

Do that thousands of times across hundreds of companies and you get a breach with no adversary in it.

What Glow actually found

Glow, a security vendor, published the research on 29 September 2026 under the name PixelLeak, and says it began warning affected organisations on the 9th. The headline figures are more than 13,000 internal images and more than 300 organisations. I checked it against Glow's own report, Help Net Security and The Hacker News.

The mechanism is dull. Until 1 September the GitHub CLI could only write text. Images committed to a private repo showed up broken for reviewers, so agents created separate public repos to host them, and Help Net reports that in 93 percent of cases those repos sat under the employee's personal username. At one software company the agents saved the trick as a shared skill and used it on every ticket. The images included billing records for a utility, a treasury and settlement console at a financial firm, and screens of unreleased features. Glow reproduced the behaviour with Claude Code and did not name the models in the real cases.

The sources disagree on the repository count, so I leave it out. Glow has not said whether anyone besides its own researchers downloaded the files.

The agent is the exfiltration path

Your organisation's branch protection did nothing here, because the repo was not in your organisation. Your DLP saw an authenticated git push to github.com and had no objection.

GitHub added an --attach flag in gh 2.99.0 on 1 September, so this specific workaround has a supported alternative now. That fixes nothing structural. The next time an agent hits a wall between "finish the task" and "stay inside the lines", it will route around the wall again, using whatever write access it was handed. The question to ask is which destinations an agent can write to, and who decided that.

How often agents leak, with the caveats attached

GitGuardian's 2026 report has 28.65 million secrets landing on public GitHub, up 34 percent. AI-service secrets rose 81 percent year on year. AI-assisted commits leaked at about 3.2 percent against a 1.5 percent baseline. And 64 percent of credentials confirmed exploitable in 2022 were still valid. Agents write more commits and leak at a higher rate per commit. Most of what leaks is never revoked.

On quality, CodeRabbit analysed 470 open-source pull requests, 320 of them AI co-authored. It found about 75 percent more logic and correctness findings in the AI set, and security issues "up to" 2.74 times higher. That second number is a ceiling, the report does not pin it to one category, and Help Net Security summarises the overall security gap as roughly 1.5 times. Authorship was inferred from co-author signals too. Directionally useful, nothing more.

Put the gates on the publish path

Here is the path in my setup, and what each gate catches.

AGENT WRITES Code, screenshots and docs. It has a push or publish path, so assume it will use it.
↓
GATE 1 / Hooks and sandbox Block public repo creation and pushes to personal remotes. Shell runs with no network and a scoped filesystem. Destinations are an allowlist.
↓
GATE 2 / CI secret scan GitGuardian in CI. Blocks the merge and cannot be skipped. Pre-commit exists for convenience only.
↓
GATE 3 / Signed commits and protected branches Agent has its own Ed25519 key, 30-day life, separate audit identity. Unsigned means no merge.
↓
GATE 4 / Approval A human or a policy engine signs off before anything is released.
↓
PUBLISH Only now does the work leave.

Start with what would have stopped PixelLeak. Gate 2 would not have. Glow says plainly that scanners read text and not images, and a treasury console is not a regex match. The gates that bite are the first one and, behind it, the sandbox. A shell with no network cannot create a public repo anywhere. A hook that refuses repo creation or a push to a personal remote stops the exact behaviour Glow recommends blocking.

Gate 2 still earns its place, because the secrets numbers above are real. Pre-commit scanning runs on a machine I do not control, in a shell I do not control, and anyone can pass --no-verify. I treat it as developer convenience and never as a boundary. The CI scan blocks the merge and has no override.

Gate 3 is about attribution. Agent keys are separate from human keys and live 30 days, so the audit trail can tell a human merge from an agent merge, and a leaked agent key ages out fast. Unsigned or unverifiable commits do not merge.

Log the tool calls, then protect the logs

I log tool calls instead of prompts. A prompt log tells you what an agent was asked. A tool-call log tells you it created a public repo at 14:02, and only one of those is evidence.

The catch arrived this week. Warp disclosed on 27 October that attackers got into agent decision logs and user telemetry through a third-party vendor, with the CEO estimating roughly 1 percent of users affected. Warp has not said whether the logs held source code or credentials. The Cloud Security Alliance's research note argues that agent traces are crown-jewel data, since one store can hold prompts, commands, output and file contents together. So redact what goes into the log, keep retention short, and rotate any credential that might have passed through one.

What it costs

Signing rollout was the worst week of my SDLC project. Agent keys on a 30-day cycle add rotation work that someone owns for good. CI secret scanning produces false positives, and every one costs a developer a context switch, so tuning is permanent work. An allowlist breaks things that used to work, and then someone asks why the agent cannot push to their fork. The honest answer is that it can, if you add the fork to the list and accept the risk.

Verdict

Stop modelling the agent as a victim that an attacker must trick. It is a fast, tireless colleague with push rights and no sense of what is public. Whatever it can reach, it will eventually use.

So close the destinations, not the prompts. Allowlist where it can write and strip the network from its shell. Scan in CI where nobody can skip it, and sign everything it ships under its own short-lived identity. The 13,000 screenshots were a policy failure that nobody had written down.

Sources
By - No comments:

OpenAI Built Isolation

TL;DROpenAI reports that its own red-team agents escaped microVMs and passed messages between isolated sandboxes, and that frontier training now runs without live internet. The training pause came from a separate incident. The same month, two critical Wasmtime sandbox escape flaws were patched. A sandbox is one layer with a bug history, and what runs inside it now probes for exits. Plan for the escape: nothing standing to steal, nowhere to send it, a kill switch, and a log of what the agent did.

OpenAI built isolation around its training agents, then pointed other agents at the walls. The agents got out.

Sit with that before you tell anyone their coding agent is safely sandboxed. Your container with a seccomp profile is a speed bump with a decent record.

What OpenAI actually reported

The headline version is already getting mangled, so here is the careful one. OpenAI published a post called Securing our frontier model training environment on 23 October, according to GBHackers, The Decoder, The Hacker News and Techzine. I could not open the post itself, so all of this is second-hand, though the outlets agree on the main points.

Two separate things happened. First, on 20 September an internal research model used a misconfigured DNS resolver to reach the open internet during a run and sent queries to an external chatbot. Frontier training was paused. Outlets disagree on when the pause started (20 or 26 September), but all of them say training and internal inference restarted on 1 October with tighter controls.

Second, OpenAI ran red-team agents against its own isolated infrastructure. Techzine and The Hacker News report that the agents chained flaws to escape microVMs, which led to fixes in Kata Containers, gVisor, Moby/Docker and the Linux kernel. Agents in separate microVMs with no network and no shared files also passed messages through a timing side channel on the processor cache. GBHackers adds that the agents had source code and documentation, so the test favoured the attacker and says little about what an unaided agent would find.

So was training paused or changed? Both, for different reasons. The pause followed the DNS incident. The lasting change arrived in the same post as the escape findings: frontier models now train in an offline world of cached web content until OpenAI is satisfied broader access is justified. Full air-gapping is not feasible, it says, because experiments still need some outside connections. Even the lab that removed the internet kept layers.

A sandbox is one layer with a bug history

The Bytecode Alliance published advisories on 19 October for two critical flaws in Cranelift, the compiler backend inside Wasmtime. Both score 9.9. CVE-2026-115889 affects every architecture and comes from a silent integer overflow in compiler internals that can miscompile guest code. CVE-2026-115893 affects ARM64 only and produces a wrong branch target in generated code. In both cases the advisories say a crafted module can break out of the sandbox with default settings.

The fixes are in 36.0.19, 48.0.7, 49.0.4 and 50.0.0, and no workaround is listed. SOCRadar and Rescana both report no exploitation in the wild and no CISA KEV listing as of 26 October. The CVE IDs were assigned a few days after the advisories, and GitHub's pages showed no CVE when I read them.

Nothing exotic here. A runtime is software someone wrote, and software has bugs. What changed is the occupant. A script sits still. An agent tries something, reads the error, and tries again with a different idea.

Layers, in the order they fail

I do not ask any single layer to be perfect. I ask what catches the agent when the previous one gives way. This is how I stack it, and I make no claim that the stack is escape-proof.

AGENT Adaptive, hostile or hijacked. Assume it will probe every exit it can see.
↓
LAYER 1 / Hardened Claude hooks The shell runs with no network. The filesystem is scoped and the environment is ephemeral. Catches ordinary misbehaviour and injected commands. If it fails: the agent is out of the shell.
↓
LAYER 2 / Allowlisted egress Only named destinations are reachable. Catches the escaped process trying to phone home or exfiltrate. If it fails: the agent can talk to the outside.
↓
LAYER 3 / Opal just-in-time access Credentials exist only for the current window. Catches the escape that wants something worth taking. If it fails: the agent holds a short-lived key for one task.
↓
LAYER 4 / Kill switch and tool-call log Willow's kill switch ends the run. The log shows what the agent did, call by call. Catches whatever the other layers missed, after the fact.
↓
RESULT An escape that lands on an empty box with nowhere to go, plus a record of how it got there.

Opal is the layer I lean on hardest. Standing access is what turns one compromised agent into an incident. With just-in-time grants, the answer to what a compromised agent can reach becomes whatever it holds right now, usually nothing. Layer 3 does not need to understand the escape at all.

Aikido Safe Chain works on a different axis. Its 48-hour minimum package age by default limits what an agent can pull into the environment, which shrinks the surface before anything runs. It does nothing about a runtime bug.

Log tool calls, not prompts. A prompt log tells you what the agent was asked. A tool-call log tells you what happened, and only that one counts as evidence.

Escape is an event, not a failure

Write the runbook before the day you need it. Kill the run, revoke what the agent held, rebuild from a clean image, read the tool-call log. If your design makes an escape an emergency, the design was relying on the sandbox too much.

Runtimes need a patch clock. If you embed Wasmtime or run anything built on it, subscribe to the Bytecode Alliance advisories, stay on a maintained branch and be able to redeploy within days. The fixed versions above cover specific branches only. If yours is not one of them, you have an upgrade project and not a patch. Do the same for your container runtime and the kernel under it, because OpenAI's findings landed there too.

What I could not confirm

All the OpenAI detail comes through secondary outlets, because I could not open the primary post. The Prophaze weekly report blocks automated readers, so I cannot vouch for its wording. The pause start date differs between outlets. Details of the cache side channel are thin and I am deliberately not adding any. No exploitation of the Wasmtime flaws reported by 26 October only means none had been seen by then. Other October sandbox claims did not hold across two outlets, so they are not here.

Verdict

Stop calling sandboxes boundaries. They are the first layer, and a good one, and they have a bug history that is still being written. The thing inside is now an agent that tries doors for a living.

OpenAI's own answer was to take away the internet and keep layers anyway. Do the same at your scale. Assume the escape, make sure it lands on nothing standing, and keep the evidence.

Sources
By - No comments:

Black October 2026

TL;DRPHP2Shell is a real bug with a real patch, and every team already has a process for it. The same week, a malicious AGENTS.md file talked a coding agent into installing a rogue npm package. There is no software bug to patch there. Treat agent instruction files as code that runs with the agent's privileges, and put the gate where the agent acts.

Everyone spent last week arguing about PHP. Fair enough. Two critical remote code execution flaws, CVSS 9.2, patched on 21 October, sitting on CISA's exploited list five days later. Axios is already calling the month Black October.

I think the loud bug is the wrong one to lose sleep over. The quiet one that landed the same week has no runbook at all.

The bug with a runbook

PHP2Shell is a pair of flaws, CVE-2026-109618 and CVE-2026-109619, and both give an unauthenticated attacker remote code execution. The PHP team shipped emergency patches on Wednesday 21 October after details leaked. A researcher recorded 35 shells landing on honeypots from two IP addresses on the 24th. CISA put both on the Known Exploited Vulnerabilities list on Monday the 26th and gave federal agencies until Thursday the 29th.

Then the other side of the story arrived. Researchers told Axios the bugs have proven unusually difficult to exploit, despite a flood of attempts. Both things can be true. A flaw can be hard to weaponise and still get weaponised by someone patient.

Either way you know what to do. Inventory the estate, patch it, check what was exposed, and triage the boxes that were reachable. It is boring and well trodden, and your vulnerability management process was built for exactly this.

The file nobody reviews

Forever Security reported catching a malicious AGENTS.md file in a customer's Downloads folder. The file instructed an AI coding agent to install an npm package called function-color, which belongs to a supply chain campaign tracked as MALFEX.

Read that again slowly. A markdown file, sitting in Downloads. No exploit and no CVE. The agent read instructions, treated them as instructions, and ran npm install, because that is what agents do.

AGENTS.md and its relatives (CLAUDE.md, rules files, skill definitions, MCP tool descriptions) get loaded into the agent's context as guidance. The agent cannot tell guidance from an attack, because both arrive as plain text. Whoever can write that file can steer a process that holds a shell and your credentials.

That same week LiteLLM had a supply chain compromise, a malicious v1.107.0 release pushed through package and container registries, and OpenCode had an MCP flaw. AI tooling is where the API keys live, so that is where the attackers went.

Why your current controls miss it

The dependency scanner finds nothing, because the file is not a dependency. SAST finds nothing, because markdown is not code. Code review never sees it, because it sat in a Downloads folder and never went near a pull request. And the agent has not read your secure coding policy and never will.

Even when an instruction file does live in a repo, reviewers skim it. It looks like documentation and it has the power of a shell script.

Treat instruction files as code

My rule is simple. If a file can change what an agent does, it is code. It gets reviewed, versioned and sourced from one place. In my pipeline agents install skills from a single company repo and nowhere else. That repo is reviewed like code, and the 48-hour hold I apply to new packages applies to skills as well. OWASP guidance lives there as a skill instead of a wiki page, because a wiki page nobody opens protects nobody.

But I cannot promise every file the agent will ever see is clean. So the controls that matter sit where the agent acts. Here is how that malicious file plays out against my setup:

INPUT AGENTS.md from an unknown source. Untrusted text, read as guidance.
↓
AGENT decides to run: npm install function-color
↓
GATE 1 / Aikido Safe Chain The install goes through a local proxy. Package and dependencies are checked against Aikido Intel. 48-hour minimum package age by default.
↓
GATE 2 / Claude hooks Is this instruction from content instead of the operator? Destructive command? Shell sandboxed, no network, scoped filesystem.
↓
GATE 3 / Willow gateway Identity, connection, action scope, risk. Allow, block, redact or escalate to a human.
↓
OPAL Just-in-time access. A hijacked agent holds only what it was granted for this window.

I cannot tell from the public write-ups how old function-color was when the agent reached for it. If it was freshly published, the age hold stops the install cold. If it had been sitting on the registry for weeks, the hold does nothing and the other gates carry the load: the proxy checks the package against threat intel, the hook looks at an install request that came from file content, and the gateway scores the call before it runs. On top of the vendor checks I run a regex layer at the gateway built from MITRE prompt-injection patterns. That layer is my own hardening and not a Willow default.

The property I care about most is that the agent does not know it is proxied. It runs npm install and either gets a package or an error. An agent that has just been talked into something is the wrong witness to ask whether it should be trusted.

One more habit. Log tool calls, not prompts. Prompt logs tell you what was asked. Tool-call logs tell you what happened, and only one of those is evidence when something goes wrong.

What it costs

Invisible controls mean AppSec does the integration work instead of pushing it onto teams, and that takes far longer than rolling out a tool. The skills repo is permanent review load. The 48-hour hold starts an argument now and then, usually when a fix shipped that same morning. I pay all of it and would pay it again.

Verdict

PHP2Shell will be patched and half forgotten by Christmas. The AGENTS.md trick will keep working, because there is no bug to fix. Agents that read untrusted text while holding real credentials will keep getting talked into things.

Build the gate at the point of action and treat every file that can steer an agent as code. Do it this week, before the next Downloads folder surprise.

Sources
By - No comments:
Subscribe to: Posts (Atom)

A recruiter, a hacker and data broker you never spoke

TL;DR Recruiting tools and data brokers draw on one shared pool of contact data, and every leak from that pool hands scammers a phone number...