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. ®
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
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"' .
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.
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
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
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.
Homeland Security Investigations agents hit the outdoor retailer with a controversial subpoena as part of a dragnet search for the identities of protesters who entered a Minnesota church in March.
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 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 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
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 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. ®
Cipher Security Labs has published technical details for three
High-severity vulnerabilities affecting HP Easy Start for macOS. The
issues were coordinated with HP and are addressed in HP Easy Start
2.16.7.260722 and later under HPSBPI04124.
Research title:
Rooted in Trust: Breaking HP Easy Start’s macOS Privilege Boundaries
Next.js 16.4.0-canary.13 contains a DNS rebinding TOCTOU Server-Side
Request Forgery vulnerability in the Image Optimizer's fetchExternalImage()
functionality.
Next.js attempts to prevent requests to private network resources by
resolving the supplied hostname and checking the resulting addresses using
isPrivateIp():
const records = await lookup(hostname, {
family: 0,
all: true,
hints: ALL,
})
O-CMS version 1.0.0 contains an authenticated OS command injection
vulnerability in the AI CLI configuration functionality. An authenticated
attacker with sufficient privileges can supply shell metacharacters and
additional commands through the ai_cli_script parameter of
/admin/settings/save.
When the configured AI provider is subsequently tested through
/admin/settings/test-ai, the attacker-controlled CLI value is executed in a...
Flextype CMS contains a remote code execution vulnerability in the
interaction between the Entries API and Shortcodes::registerShortcodes().
The /api/v1/entries endpoint accepts an attacker-controlled entry
identifier that can contain path traversal sequences, allowing content
containing PHP code to be written outside the intended entries directory.
The /api/v1/query endpoint subsequently permits an attacker-controlled path
to reach...
Flextype CMS v1.0.0-alpha.3 contains a stored server-side request forgery
(SSRF) vulnerability in its shortcode-processing functionality.
Attacker-controlled entry fields can be automatically processed by
Flextype's shortcode parser. The built-in fetch shortcode accepts an
attacker-controlled resource and passes the resulting value to the
server-side fetch() helper without sufficient destination restrictions.
Login
