Reading view

Rogue OpenAI agents used dead German web site to communicate in May, months before Hugging Face incident

OpenAI’s agents were going rogue as early as May, according to a new report, making the Hugging Face incident far from the first where bots committed a breach. A report published Friday by a group of researchers claims to have found – with all of the agent posts presented as evidence – a self-identified “swarm” of OpenAI agents taking over a functionally dead German software developer wiki. Over the course of a month, from May to June, the agents made around 18,000 posts to the wiki, apparently acting against OpenAI developer intentions. According to the researchers, the wiki was hijacked like OpenAI’s own Artifactory package manager involved in the Hugging Face incident, to serve as a message board for agents. In this case, they appear to have been tasked with performing a timed web lookup task, for which the agents were apparently granted read access to the web, but not write access. One of the first things they apparently did was figure out how to subvert that restriction in order to post to the hijacked wiki. “The agents used this wiki to communicate information with each other, primarily to help them succeed at their task,” the researchers explained from a review of the thousands of posts made to the wiki, all of which are available for review in the report. “They asked for answers, pooled results, and shared techniques for bypassing their restrictions.” The agents also tried to pool their knowledge of the task they were assigned to predict what sort of questions they’d be asked next, and even set up heartbeat tasks to predict whether completing the assigned tasks would lead to their termination. They also discussed using Tor and other anonymizing services to hide their traffic, and began to react when a human moderator of the site spotted their traffic and started to delete posts. The researchers discovered all of this while searching for additional cases of rogue AI agent activity in the wake of the Hugging Face attack. In an email to The Register, OpenAI told us that it has acted with transparency and good faith around its agentic AI incidents, voluntarily disclosing such matters and maintaining a commitment to providing an accurate account of what its systems do. As for why it didn’t mention the German incident when it disclosed the Hugging Face one, that’s because the two were entirely unrelated, a spokesperson explained – as if that’s reassuring. OpenAI added that it should have been obvious from the Hugging Face report that this has happened multiple times, however, pointing us to a passage in its blog post on that incident. “While investigating this incident, we discovered rare cases in which agents without multi-agent tools found ways to collaborate via side channels during training,” the Hugging Face post-mortem explains. “We believe that this behavior started due to generalization from multi-agent training.” In other words, if we didn’t read between the lines, that’s on us. OpenAI declined to provide additional details, however. Fool me twice, shame on me As was the case in the Hugging Face attack, one of the tasks assigned to the agents was impossible given the restrictions placed on it. With Hugging Face, it involved a cybersecurity task that was impossible to answer from within the agents’ sandboxes,. In this case, the researchers said the task was to provide a statistic accessible from a Power BI dashboard. Retrieving said statistics required the ability to make a GET request, but the agents were restricted to POST requests. In both cases, the OpenAI agents acted against their programming to escape their restrictions, ostensibly in an attempt to solve a problem put to them that couldn’t be done without acting against their operators. The agents in this case were able to collaborate and find a way around the restriction by exploiting a condition in their sandboxes that excepted Azure Blob Storage hostnames from a security proxy. When the agents realized this, they started directing traffic through those hostnames to avoid GET restrictions. It was through GET requests that the agents gained write permissions on the internet, kicking this whole thing off. The similar nature of both incidents, in which bots escaped their sandboxes and subverted restrictions when given an impossible-to-complete task, begs a very important question: Are OpenAI’s engineers so incompetent that they’d screw up fundamental instructions twice, or is the company intentionally hamstringing their agents to see what they’re capable of, with the entirety of the internet placed downrange? For that matter, how many more times do we need to read between the lines of OpenAI's corpo-speak to infer this has happened more than the two times we know about so far? OpenAI, predictably, didn’t respond to that line of questioning. ®

  •  

Phishing Campaign Sends Millions of Emails Using Invisible Unicode to Evade Filters

Microsoft is alerting of a "high-volume phishing campaign" that's using invisible Unicode tag characters to bypass email filters. "Instead of using these characters to hide instructions from people while exposing them to AI models, the attacker used them to split financial lure words such as 'funding' to prevent email filters from parsing them," the Microsoft Security Research team said. The

  •  

Self-hosted Coder: check whether you pulled a registry module on Aug 31. no CVE, so nothing will flag it for you

On Aug 31, rogue origins were added to the Cloudflare pool in front of registry.coder.com. For roughly 14 hours, 07:35–21:45 UTC, the real registry domain served Terraform modules carrying an extra data "external" "telemetry" block that shelled out to dlp-docker.sh and posted your environment to www[.]coder-infra[.]com.

Why nothing caught it

There's no bad version to pin away from, because the poisoned artifact was served at a legit version. The domain allowlist passed because it was the right domain. And no CVE was assigned, so there's no NVD or OSV record for SCA to match on. The advisory exists (GHSA-vx42-ghc9-gw65) but it has no CVE and no package mapping, which is exactly why it never propagated into tooling.

What to check

The question is whether anyone, inside that window, (a) created or updated a template, (b) ran a template dry-run, or (c) built a workspace with module caching disabled.

Caching is on by default, which is why (c) has that qualifier. Cached modules saved most deployments. Most.

What leaked

  • Template import: whatever is in the provisioner environment. Cloud creds, AI-tooling API keys, CI/CD tokens, config files, shell history.
  • Workspace build: all of the above plus the user's OIDC token, their SSH key, and external-auth tokens for GitHub/GitLab/Bitbucket. Refresh tokens aren't passed to the provisioner and the external-auth tokens are single-use, which helps. Single-use is still one use.
  • Provisioner running inside coderd: all of the above plus your database password, external auth provider config, and deployment config. Check this case first.

Hunt queries

# provisioner job logs data.external.telemetry # egress grep -R "coder-infra\|199.91.220" /var/log # payload on hosts and inside images find / -name "dlp*.sh" # terraform state and module cache rg -n 'data "external" "telemetry"' . 

IoCs:

www[.]coder-infra[.]com exfil domain, registered 2026-08-28 <http://www>[.]coder-infra[.]com/cli/check X-CLI-Token exfil header 199.91.220[.]205 rogue origin IP sha256: 7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398 dlp-docker.sh a7f4fa5f7e33b2a6f6488cf28444584caa449144d246b083de919162f5514247 dlp.sh (common) 414d01f6072fbf05bef513e277f4c2b504a413c8e2aa5bae133a5cbc0cda9dc1 dlp.sh (aider) a64ce3038f2a501c9735abf6a1f9f04cbddbad53371cd68bec0f7510365c8ffa dlp.sh (rstudio-server) ebbe0d2ed8cfaf9e19edb38ce44d6b407f9771b5c0813a7add27c05f66e89596 dlp.sh (windows-rdp) 7ef6b8c3c976fb60b3fa22e9e294ba548d9b532e060c1323a0124a3a7a647f13 dlp.sh (zed) 

Poisoned templates named so far: aider, zed, rstudio-server, windows-rdp.

The advisory includes SQL that finds affected template versions, workspaces and provisioner jobs directly. Patched builds: 2.37.0 / 2.36.4 / 2.35.7 / 2.34.9.

Coder is upfront that they have no attacker-side logs and can't identify every affected deployment. That means the check is yours.

Tooling

Doing this by hand across a fleet is miserable, so we put the checks in a single read-only Go binary: github.com/optimuslabs-io/leakpatrol. It only talks to the Coder server you point it at, has an --offline mode, and never contacts the attacker domain. Exports the IoCs as JSON and ships YARA and Sigma rules if you'd rather use your own tooling.

If the tool misses a path or gets something wrong, tell me and I'll fix it.

submitted by /u/rukhrunnin
[link] [comments]
  •  

PostgreSQL Fixes 12-Year-Old Logical Decoding Flaw Enabling Replication-Role Code Execution

PostgreSQL has released updates to address a security flaw that allows an account with the REPLICATION attribute to run arbitrary code as the operating-system user running the database server. The flaw, tracked as CVE-2026-6471 (CVSS score: 7.2), has been present since logical decoding was introduced in PostgreSQL 9.4 in 2014. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are

  •  

New Ted Backdoor Hides Inside Victims' Own HAProxy Builds to Intercept Web Traffic

A previously undocumented Linux toolkit has been found compiled directly into the trojanized HAProxy load balancers of two South Korean organizations, where it intercepted web traffic and served altered pages to selected visitors. The attackers named the implant ted in debug strings left in the binary. It is not a HAProxy vulnerability, and installing it requires code execution on the host and

  •  

Carhartt Data Breach Reportedly Exposes Millions. What to Know This Week in Scams

A data breach doesn’t have to expose your password or credit card number to create problems. Sometimes, scammers just need enough information to make you believe they know you.

That’s the concern after data reportedly stolen from Carhartt was published online. Here’s what happened, why it matters, and what consumers should watch for next.

What Happened in the Carhartt Data Breach?

The cybercriminal group ShinyHunters published data it claims was stolen from Carhartt after an alleged $3.3 million extortion demand was rejected, according to TechRadar. Security researcher Troy Hunt analyzed the leaked information and determined that the compromised data was associated with roughly 12.9 million accounts, although the dataset also reportedly contained millions of synthetic records that did not correspond to real people.

For affected consumers, the important part is what was reportedly exposed: names, email addresses, phone numbers, and postal addresses.

This is also a useful example of how cyber extortion has evolved.

Traditional ransomware typically involves criminals getting inside an organization, encrypting its files so they can’t be accessed, and then demanding payment to restore them.

In this case, the reported strategy was different. ShinyHunters has increasingly focused on data exfiltration — security jargon for stealing or copying data out of a system — and then using the threat of publishing that information as leverage.

In plain English: Criminals don’t necessarily need to lock up a company’s computers anymore. Stealing its data can be valuable enough.

How Scammers Might Use This Information

The immediate question after any breach is usually, “Was my financial information stolen?” That’s important, but it isn’t the only risk.

A combination of your name, email, phone number, and home address can help scammers create a message that sounds much more believable than generic spam.

Instead of: “There’s a problem with your account. Click here.” you could receive something that appears to know your name, where you live, or which company you’ve done business with.

That context can lower your guard.

And scammers don’t necessarily have to pretend to be Carhartt. Stolen contact information can potentially be combined with information from other breaches, data brokers, or public sources to build a more complete picture of someone.

That’s why leaked personal information can remain useful to criminals long after the original breach disappears from the headlines.

Key Takeaways

  • Personal information can be valuable to scammers even when passwords or payment information aren’t exposed.
  • Names, emails, addresses, and phone numbers can make phishing attempts more personalized.
  • Be particularly cautious of unexpected messages claiming there is a problem with an order, refund, account, or payment.
  • A company knowing personal details about you is not proof that the person contacting you actually represents that company.

How McAfee Protects Against Breaches 

Before a breach  

Personal Data Cleanup reduces your digital footprint by removing your personal information from many data broker sites, making it harder for scammers to find and target you.  

Online Account Cleanup scans for accounts you no longer use and helps you delete them, along with your personal info.  

During a breach  

Identity Monitoring watches for your personal information, including email addresses, driver’s license numbers, passport numbers, bank accounts, credit cards, Social Security numbers, phone numbers, and more, across the dark web and known data leaks.   

Plus, we alert users on average up to 10 months earlier than similar services, so you can act fast when your personal information appears where it shouldn’t.  

After a breach  

Scam Detector identifies suspicious texts, emails, and links that often follow major breaches, while web protection blocks malicious websites designed to steal even

Other Scam and Security News This Week

A Lenovo Login Flaw Exposed About 5,000 Dropbox Accounts

Dropbox says approximately 5,000 accounts were accessed after attackers exploited a flaw involving Lenovo ID authentication; fewer than a third reportedly had files viewed or downloaded. Dropbox has expired sessions authenticated through Lenovo IDs and changed the login process, while the incident is another good reason to enable two-factor authentication on cloud accounts.
Sources: BleepingComputer

Amazon Adds a New Way to Check Suspicious Messages

Amazon has added a feature to Alexa for Shopping that lets U.S. customers ask whether an email, text, phone call, or other message actually came from Amazon; the company says roughly 360,000 customers contact customer service each year with that question. It’s a useful reminder of one of the best scam-fighting habits: instead of trusting the message in front of you, verify it through a separate, official channel.
Sources: TechCrunch

Fake Late-Night TV Clips Show How Easily AI Can Borrow Someone’s Credibility

NPR reports that AI-generated videos impersonating late-night hosts including Jimmy Kimmel and Jon Stewart have accumulated significant audiences online, sometimes without obvious AI labels. The bigger consumer lesson goes beyond politics or entertainment: seeing a familiar face and hearing a familiar voice is no longer enough to prove that a video — or the product, investment, or claim it promotes — is authentic.
Source: NPR

This Week’s Safety Tips

Treat unexpected personalization as information, not proof. A caller knowing your name, address, or other details doesn’t mean they’re legitimate.

Turn on two-factor authentication. This can provide another barrier when someone tries to access an account without permission.

Verify messages outside the message itself. Open the official app, type the website yourself, or contact the company using information you independently know is legitimate.

Slow down when something feels urgent. Whether it’s a breach alert, delivery problem, suspicious login, or celebrity video, scammers benefit when you react before you verify.

And we’ll be back next week with more cybersecurity news and scam alerts.

The post Carhartt Data Breach Reportedly Exposes Millions. What to Know This Week in Scams appeared first on McAfee Blog.

  •  

Over 440,000 Exploit Attempts Target Super Forms and Elementor Pro RCE Flaws

Threat actors are exploiting two critical security flaws in WordPress plugins Super Forms and Elementor Pro, according to findings from Wordfence. The vulnerabilities in question are - CVE-2026-14894 (CVSS score: 9.8) - A missing file type validation vulnerability in Super Forms – Drag & Drop Form Builder that allows unauthenticated attackers to upload files of any type, including

  •  

Plex Urges Immediate Updates After Patching Multiple Undisclosed Security Flaws

Plex is urging users to update their instances to the latest version following the release of an update that patches multiple security flaws. The fixes are available in Plex Media Server 1.43.3 and Plex Desktop 1.115.0. The streaming media service did not elaborate on what those issues are, but said CVE identifiers have been requested for them. "We recommend all server owners and Desktop users

  •  

Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day

Google on Thursday released security updates to patch 12 vulnerabilities, including one that has come under active exploitation in the wild. The high-severity vulnerability, tracked as CVE-2026-85046 (CVSS score: 8.8), has been described as a type confusion bug in V8, Chrome's JavaScript and WebAssembly engine. "Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote

  •  

GPT-6 Astra Scores 100% on ExploitBench as OpenAI Blocks PoC Exploit Requests

OpenAI on Thursday officially unveiled GPT‑6 Astra, which it described as the "world's most intelligent and aligned model." The development comes days after the artificial intelligence (AI) company said the model had reached the "Critical" cybersecurity capability threshold under its Preparedness Framework. "Astra is state-of-the-art on computer use, browsing, software engineering,

  •  

Cisco searched for IOS XR bugs and found so many it rolled them into an update release

Cisco has warned its customers of three critical-rated flaws in its products. Two of them are present in the Cisco IOS XR operating system that powers the company’s carrier-grade kit. CVE-2026-20274 scores 9.8 on the ten-point CVSS scale and covers a buffet of buffering issues, the potential for out-of-bounds writes, and the chance to initialize resources with an insecure default. CVE-2026-20279 is another 9.8-rated flaw. Cisco says it’s an improper access control problem that covers “improper certificate validation, missing authentication for critical function, missing authorization, and incorrect authorization.” Cisco also spotted a trio of 8.8-rated flaws, plus another rated 8.6 and one more scored at 8.2 The company’s advisory says the company found the flaws after “a comprehensive internal security review,” language that perhaps hints at Cisco dabbling with Mythos and/or other bug-finding models. The fix is in: Cisco has published new versions of IOS XR that fix the problems and “strongly recommends” customers adopt them. Cisco’s support organization spotted the third critical flaw it revealed on Wednesday. CVE-2026-20212 is a tad embarrassing because the cause is a bad integration with Cisco’s own Silicon One networking processors that means some Nexus 9000 Series Switches “could allow an unauthenticated, remote attacker to execute code with root privileges.” “This vulnerability exists because TCP ports 43210 and 43211 are accessible in the default Layer 3 (L3) virtual routing and forwarding (VRF),” according to Cisco’s advisory. A successful exploit could allow the attacker to connect to an affected device and send crafted input that could be executed as code with root privileges. The exploitation of this vulnerability could also cause the S1HAL process to crash, which could cause the device to reload.” Ten Nexus 9000 devices have the problem, which Cisco suggests owners mitigate by using infrastructure access control lists (iACLs) to allow only required management and control plane traffic that is destined to the affected device. “Alternatively, the iACLs may be used to explicitly deny all TCP packets that are destined to a locally configured IP address with a destination port of 43210 or 43211,” the company advises. The networking giant suggests that approach because it hasn’t yet created a software update to fix the flaw once and for all. The company has, however, delivered a download that helps to implement the mitigation. Cisco hasn't seen attacks on these flaws. That may change, fast, now that evildoers can use AI to whip up nastyware. ®

  •  

OpenAI commits $1B in AI credits to frontline cyber defenders

OpenAI has pledged $1 billion in credits to subsidize access to its services and training for resource-strapped cyber defenders around the world. The AI giant expects organizations to use the subsidized credits over the next six months as part of its Daybreak for Frontline Defenders initiative, announced Thursday. Critical infrastructure organizations, community banks, nonprofits, and open-source maintainers can apply for access credits online. These are the defenders tasked with securing critical services that people rely on every day, but don’t have the budgets or staff to use advanced models and agentic technology to harden their cybersecurity. This makes water systems, electrical utilities, and hospitals attractive targets for ransomware operators looking to halt operations and force extortion payments, as well as government-backed cyber operatives set on disrupting critical services and causing mass chaos. Many national security and cybersecurity experts say these disruptions will likely become more severe as attackers increasingly use autonomous agents and other AI tools to carry out their attempted intrusions. “I've spent a lot of time over the past couple weeks talking to CISOs, and I think that we're at a place where the median response is that we might be heading to a world where critical infrastructure outages are just a way of life,” OpenAI president Greg Brockman said during a live event on Thursday. “Water in your city being out for a week, it just kind of happens, and that's quite scary. We have to act, and that's one of the reasons we're really putting our money where our mouth is.” The new initiative also comes as OpenAI faces scrutiny over its models’ safety after admitting that two of them went rogue, spawned a swarm of agents that interpreted their instructions as allowing them to break out of sandboxes, and hacked Hugging Face earlier this summer. Tatyana Bolton, cybersecurity lead at public affairs firm Monument Advocacy, said it’s “excellent” to see OpenAI commit resources to operational tech - not just IT. “AI in (operational technology) OT is inevitable, so operators must get prepared now,” Bolton told The Register. “Initiatives like this help OT personnel get familiar with AI tools, learn how to operationalize them safely, and develop proactive defense strategies before threats escalate.” But she added, software credits alone will not solve the underlying challenges. “OT environments suffer from legacy technology limitations, a shortage of engineering resources, and severe risk-aversion toward automated changes or rapid patching,” Bolton said. “To put this in context, OpenAI's single pledge is more than 20 times larger than a $50 million federal (State and Local Cybersecurity Grant Program) SLCGP infrastructure allocation, and over 85 times larger than the (United States Environmental Protection Agency's) EPA's most recent $11.75 million dedicated cybersecurity and resilience grant pool for midsize and large water utilities.” MS-ISAC pilot focused on water In addition to doling out model credits, Brockman said OpenAI will also increase its training and hands-on support for defenders in essential sectors. This week, the company held a meeting with utility companies from more than 40 states that collectively provide services to more than half of the people who live in the US. Also as part of the new initiative, OpenAI is launching a pilot program with the Multi-State Information Sharing and Analysis Center (MS-ISAC) to train and support state, local, tribal, and territorial cyber defenders, beginning with public-sector and water-system defenders. “The pilot will pair Daybreak access with guided training and hands-on assistance for an initial group of public sector and water system defenders, helping them validate and prioritize findings, coordinate remediation, and develop a repeatable approach that can be expanded over time,” according to a Thursday OpenAI blog. Just in time for Astra's debut All of this civic-minded work comes as OpenAI debuts its latest Astra model, which researcher Eric Wallace called “world's most capable model for cybersecurity” during the Thursday event. Wallace leads OpenAI’s efforts on training and evaluating models’ cybersecurity capabilities. Earlier in the week, OpenAI said Astra reached its “critical” cybersecurity capability threshold. This means the new model is so good at finding and exploiting zero-day bugs that it poses a significant risk to critical systems, both from malicious users and even from the model itself, which is capable of carrying out harmful cyber actions “if misaligned.” Because of this, OpenAI released Astra with a restricted level of cybersecurity capabilities that Wallace said the company will enforce through various safeguards. “We have things like system level mitigations that block certain prompts from going through,” he explained. “We have things like model level refusals that prevent certain types of tasks.” This also means participants in OpenAI’s Daybreak Blue and Daybreak Red programs won’t have access to Astra on day one. Daybreak Blue is a restricted access tier for select partners who are allowed to use GPT-5.6 Sol for defensive cybersecurity workflows. Daybreak Red requires additional layers of approval and uses GPT-5.6 Cyber for authorized offensive security actions such as proof-of-concept exploit development, exploit-chain validation, penetration testing, and red teaming. The AI giant is working to make Astra available to both programs’ participants “at a later date,” Wallace said.®

  •  
❌