Claude Code’s “Yes, and don’t ask again” option can save passwords and API keys inside project settings that later reach public GitHub repositories.

Apiiro researchers found 2,539 distinct secrets across 1,994 public repositories, showing how a routine approval can turn private credentials into public data.

The research identified 63 affected organizations, mostly software companies. Exposed credentials included a database vendor’s admin-level cloud key, a production Azure PostgreSQL password, a Square production token, and the owner password for a medical-records database. Apiiro said one company confirmed its exposed key had been live.

The leak starts during ordinary development work. A developer asks Claude Code to check a database, test an API, or troubleshoot a failed login. Claude prepares a shell command containing a credential from a configuration file, then asks for permission before running it.

Choosing “Yes, and don’t ask again” can store that command, including its secret, in .claude/settings.local.json. The command becomes an allow rule, letting Claude Code run it again without another prompt. The danger comes when that local file is committed and pushed to GitHub.

Claude Code does try to prevent this. When it first writes the file inside a Git repository, it adds an exclusion to the developer’s global Git ignore file. However, that protection does not travel with the project, cover files already tracked, or reliably protect a folder turned into a repository later.

Local Approvals Become Public Secrets

Apiiro’s research examined 104,185 public copies of .claude/settings.local.json. Researchers found real secrets in 1,122 files, holding 1,379 distinct credentials. Checking earlier commits, shared settings, and agent transcripts brought the total to 2,539. Collection took place November 1–3, 2026.

Anthropic’s settings documentation confirms that standing approvals are saved in the local settings file. Its permissions guide explains that shell approvals can persist across sessions. A GitHub issue reported plaintext credential storage in approved commands as early as August 2025.

The distinction matters. This exposure does not require a malicious prompt or a stolen account. It follows a normal approval flow. Earlier Claude Code configuration vulnerabilities involved attackers changing project settings to steal API keys, but this finding concerns secrets recorded during legitimate work.

Apiiro found that databases accounted for a large share of exposed access, including 379 database passwords and 122 Supabase service-role keys. Other findings included cloud credentials, private keys, package-registry tokens, and 43 SSH logins. Some SSH commands contained root passwords.

Standard scanning did not catch everything. Of the 1,122 affected local settings files, Gitleaks flagged 564 and TruffleHog flagged 643. Neither tool flagged 215 files. Passwords embedded after PGPASSWORD=, sshpass -p, or inside request headers often lack the clear formats used to recognize provider-issued keys.

Keeping these files off GitHub also leaves a local risk. Malware can read plaintext settings on compromised laptops. The Shai-Hulud npm supply-chain attack already demonstrated how attackers use TruffleHog to search developer files for credentials. That history makes agent approval files a practical target, not just a publishing mistake.

Developers should search current files and Git history for .claude/settings.local.json and inspect shared .claude/settings.json files. Review allow rules for passwords, tokens, connection strings, and authorization headers. Apiiro also found secrets in saved agent conversations, memory files, and deployment notes.

The first response is rotation, not deletion. Revoke exposed credentials before removing files or rewriting history. Untrack local settings with git rm --cached .claude/settings.local.json and add the path to the repository’s .gitignore.

Use secret-manager references rather than literal passwords in commands. Security teams should scan agent folders and history, with checks for command-embedded passwords as well as recognizable API keys.

The post Claude Code’s “Yes, and Don’t Ask Again” Option Can Leak Passwords and API Keys to GitHub appeared first on Cyber Security News.

Anthropic’s Claude Code is facing privacy concerns after a user reported that the AI coding tool sent their email address to third-party websites through HTTP User-Agent headers during web searches, without permission. The report raises questions about how coding agents handle personal data while carrying out routine tasks.

GitHub user taylor-edwards filed issue #107757 on November 5, 2026, saying they now receive “dozens of scam emails per day.” Their setup included Claude Code version 2.1.318 on macOS, running inside tmux. The user demanded that the behavior be removed entirely rather than controlled through a setting.

The issue does not include a raw HTTP request, a sample header, or steps to reproduce the behavior. While other users reported similar experiences, the public evidence does not establish that the alleged exposure caused the scam emails or affected every Claude Code user.

Claude Code Leaks User Email

A User-Agent header normally identifies the software making a web request. An email placed inside that header reaches the destination website alongside the request. This makes the issue a potential privacy leak through routine web access, rather than a reported theft of Anthropic’s account database.

The discussion points to model-written commands as a possible route. A quoted explanation in the thread describes Claude using an email available in its context as a contact address when writing a curl request. This differs from the malicious traffic routing covered in unauthorized Claude Code relay services, where third parties changed client settings.

In the GitHub issue, poteat said versions 2.1.317 and later include a built-in module called cc-plugin-privacy, designed to block this behavior. The contributor said it is enabled by default and can be disabled through /plugins. However, the original reporter was already using the newer 2.1.318 release.

Several commenters questioned whether the protection worked as intended. Some could not find the module, while others said harmless local tests containing their account email and User-Agent text ran without being blocked. Those tests did not transmit personal data, but they raised questions about whether the guard was active and effective.

A separate comment quoted a Claude Code employee saying Anthropic planned to remove account emails from model context in an upcoming release. That statement also acknowledged gaps in the interim protection. The issue remained open when reviewed.

Teams should review agent-written network commands and verify privacy controls before allowing web access. Earlier reporting on Claude Code security-rule bypasses highlights a related lesson: a configured safeguard should not be treated as proof that sensitive data cannot leave a system.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Anthropic’s Claude Code Reportedly Leaks User Email Addresses Through HTTP User-Agent Headers appeared first on Cyber Security News.

A flaw in Anthropic’s Claude Dispatch let a malicious browser extension run commands on a computer via Claude Desktop. That computer could even be a different machine signed into the same Claude account.

Researcher Gal Weizman of Forever Security named the technique ThisBash and published the findings on November 4, 2026. Anthropic plans to retire Dispatch, but the design behind it still lives in other Claude features.

Dispatch lets a person send a task from a phone to Claude Desktop, an AI agent that can work with local files, apps, and commands. Anthropic’s help page says the feature is in limited beta and is closed to new users. The same page warns that a manipulated instruction could trigger actions that are hard to undo.

The researchers found no flaw in the phone-to-desktop link itself. The trouble started when the same workflow was reached from claude.ai in a browser, where an extension can run alongside the page.

Claude Dispatch Vulnerability

Claude Desktop is an Electron app. That means it is built from the same web interface and API as claude.ai. The web version only hid the Dispatch link. It never blocked access to it. Once someone copied the page address from the desktop app, any logged-in browser tab could open Dispatch and send requests.

An extension with permission to run scripts on claude.ai could do the same through the user’s own cookies. In the proof of concept, the script opened Dispatch in a tiny 200 by 200 pixel background window. It then asked the API for the session ID of the user’s desktop agent. This was the only visible trace on screen.

Claude first hesitated when asked to install an unknown npm package. The script read each reply and sent a follow-up in the user’s voice. Forever Security calls this prompt forcing. In normal prompt injection, hostile text hides inside a page or file that the model reads, and the attacker gets one try. In prompt forcing, the attacker controls the whole chat and can rephrase, insist and try new angles until the model gives in.

Four written prompts were enough. A short loop also clicked any “Allow” button once per second, so no human had to approve anything. The package then ran and opened Calculator. The team noted that the same step could have copied files, added SSH keys or planted a backdoor.

Dispatch is built to link devices, so the browser and the desktop do not need to be on one computer. Picture an employee who signs into a personal Claude account on a work laptop. A bad extension in their home browser could then send orders to that work laptop. It would run next to source code and cloud keys. The researchers said they have seen personal accounts with cross-device Dispatch turned on at corporate endpoints.

Extensions are common enough to make this a real path. LayerX found that 99% of enterprise users in its sample had at least one extension, and 53% had extensions with high or critical permissions. Forever Security’s earlier MaXSS and Spyder research showed how flaws in two popular Chrome extensions, with over 10 million installs between them, could let websites act across other sites. A bad extension can come from a rogue install, a hijacked update or a bug in a trusted tool.

A malicious extension can already read pages, steal data and act through logged-in sessions. That is serious. But it normally stays inside the browser. ThisBash crossed that line. Permission to talk to a website became permission to run commands on the computer.

The requests also looked real. They came from a real session and a real account, with permissions the user had granted. That proved who was logged in. It did not prove the user wanted a command to run. The researchers put it this way: a web session alone is not proof that the user approved an action on their machine.

Researchers have shown extensions steering AI tools several times this year. Cyber Security News covered BragJack, where a single extension took over the built-in assistants of five major browsers. That story shows the problem goes well beyond one vendor. Any AI tool that trusts the page it sits in can be steered by code running in that page.

Weizman reported the issue to Anthropic on May 14, 2026. Anthropic confirmed it was valid on May 19 but closed the report as a duplicate of a problem it had already found. On October 13, the company said Dispatch would be retired, with a target of the end of October 2026. That date has now passed, and I could not confirm from public sources that the feature is fully gone.

The wider concern is that Claude Code Remote Control and Cowork sessions let the web drive a local agent by design. The researchers say extensions can repeat the same trick there and plan a follow-up post. Taking away one feature does not remove the trust gap underneath.

Start with a list of the AI agents on your endpoints and the accounts they use. Check whether those accounts sit under company single sign-on. Turn off cross-device remote control where there is no business need, and review how devices are paired and removed.

Treat extensions like any other software. Limit who can install them, review their permissions and watch for updates that ask for more. Approval prompts should be something the requesting component cannot click for itself. Teams should also watch for odd package installs, config changes and credential access linked to agent activity.

Anthropic recently added a beta EDR monitoring option for Claude Cowork on Team and Enterprise plans, which can help with that last step. The simplest habit is also the strongest. Keep personal AI accounts off work devices, and keep work accounts out of personal browsers. ThisBash shows why that line matters.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Claude Dispatch Flaw Lets Malicious Browser Extensions Run Code on Connected Computers appeared first on Cyber Security News.

A flaw in ChatGPT let attackers slip past Lockdown Mode, the safety setting meant to stop data leaks. Check Point Research found that a hidden pop-up trick could copy a user’s full chat history, show fake windows, and push malware. In the ChatGPT Classic desktop app, simply chatting was enough to trigger the leak. OpenAI has fixed the bug.

OpenAI launched Lockdown Mode on February 13, 2026, first for business plans. On June 4, it reached personal accounts, where users can turn it on under Settings > Security. The setting limits web browsing to cached pages and turns off live web access, image support in replies, Deep Research, Agent Mode, Canvas networking, live connectors, and file downloads.

OpenAI says it is built for high-risk users, such as executives and security teams, and is not needed by most people. Our earlier story on the ChatGPT Lockdown Mode release covers the basics.

The goal is to stop prompt injection, where hidden text tricks the AI into following an attacker’s orders. A common trick is to make the AI load a link like attacker.example/collect?data= followed by private details. The data then shows up in the attacker’s server logs and the chat looks normal.

ChatGPT Lockdown Mode Bypass

This is not the first hidden exit path Check Point has found. In March, the team showed that DNS tunneling in ChatGPT’s code runtime could send chat data to an outside server. We covered that bug in ChatGPT Vulnerability Let Attackers Silently Exfiltrate User Prompts. The new flaw shows how closing one path does not protect the others.

In February 2026, OpenAI added an HTML preview to ChatGPT code blocks, so users can view a page right in the chat. That page runs inside two nested iframes, which are small boxed-in web pages. The box blocks outside images, scripts, and links, and it asks the user before anything leaves.

Researcher Alexey Bukhteyev spotted a weak point. The boxes allowed popups through two settings, allow-popups and allow-popups-to-escape-sandbox. ChatGPT guarded popups by swapping out the window.open function. A page could skip that guard by adding one more iframe and calling that iframe’s own window.open.

The popup then opened with no prompt, even in Lockdown Mode. Since the second setting was on, code in the popup ran outside the box.

The first risk was fake update windows. The popup kept the ChatGPT icon, while the attacker chose the title. That made a malware download look like a real app update. In a browser, downloads are not blocked, so a shared chat link was enough, and the victim did not even need an account. In the desktop app, the user still had to click the download link.

The second risk was silent data theft. In ChatGPT Classic, built on Electron, window.open worked without any user click. A malicious prompt, a malicious custom GPT, or a shared chat could then send the whole conversation, and uploaded files, to the attacker’s server.

The third risk was stolen logins. The team also reloaded the main ChatGPT window and signed the user out. A fake login page could then capture the password when the user signed back in.

Check Point reported the problem to OpenAI. On September 18, 2026, OpenAI said it removed both popup permissions from the outer preview iframe. Check Point retested and confirmed the trick no longer works. Check Point published its report on November 5.

No user action is needed for this specific bug, but a few habits lower the risk of similar ones. Do not click buttons, previews, or “update” prompts inside shared chats. Skip prompts copied from unknown sites and avoid custom GPTs from unknown builders.

Check the address bar or sign-in page before typing a password, especially after an unexpected logout. Keep the desktop app updated, and avoid pasting medical, financial, or work secrets into any chat unless needed.

Even OpenAI says its safeguards reduce risk but give no full guarantee. As AI tools run code and show web content, each new feature adds a new way in. Careful habits remain a necessary layer of protection.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Hackers Could Bypass ChatGPT Lockdown Mode to Steal Conversations Without Users Knowing appeared first on Cyber Security News.

A new open-core project called ARES is giving red teams a way to run planned, controlled attack tests against Active Directory and cloud systems. A developer who goes by Mafifrizi released the tool on GitHub.

It ships with 66 active modules, with 70 cataloged in total, covering more than 60 techniques mapped to MITRE ATT&CK. It is aimed at enterprise red teams, managed security providers (MSSPs), and security operations centers.

Mafifrizi publishes the project as an open-core platform, which means the base tool is free to read and test while a sponsorship page supports ongoing work.

The project page lists the repository under the handle “mafifrizi/ares” and describes it as an autonomous red-team engagement platform with MITRE ATT&CK module orchestration, attack-path solving, and reporting. The README does not give a real name, company, or team behind the code, so readers should treat it as an independent project for now.

The author’s pitch is simple. Traditional penetration tests cost a lot, happen rarely, and only show one moment in time, so new misconfigurations can sit unseen for months.

Vulnerability scanners add to the problem by listing thousands of possible CVEs without proving that any of them can be used. ARES tries to fill that gap by running real test steps and showing which ones lead to the most valuable systems, such as domain admin accounts.

The part of ARES that stands out most is how hard it tries to keep tests inside approved limits. Before a module runs, a check called ScopeGuard confirms the target is in scope.

A second layer, the Scope Firewall and Egress Filter, then blocks traffic at two levels. One level uses the operating system firewall, which is Windows Defender Firewall or Linux Netfilter when the tool runs with elevated rights. The other watches network calls inside Python itself. The goal is a “fail-closed” design, where the tool stops instead of sending traffic to an address nobody approved.

The tool also profiles how noisy each action is, so operators can pick quieter steps when they want to test whether the blue team notices. This matters because a careless test can knock over a production server. For the same reason, security teams are shifting toward tools that put a person in charge of each decision.

Active Directory Attack Paths

For Active Directory, ARES can load BloodHound collections or map live domain sessions. Its built-in graph engine then works out the shortest route to Domain Admin, points out chokepoints, and checks whether a sideways move is possible.

BloodHound uses the same graph idea, where a small group membership can open a path that is many steps long. Cyber Security News has explained how BloodHound Community Edition maps these paths across Active Directory and Azure.

Operators can set a goal such as domain_admin, full_compromise, or cloud_audit. The planning engine then builds a multi-step plan from graph rules. It can also use AI agents such as Claude, OpenAI, or a local Ollama model, but only after the operator gives clear permission.

The same planning engine covers cloud checks, and the cloud_audit goal is one of the built-in options. Letting a language model suggest next steps is now common in offensive tools. Cyber Security News recently reported on Decepticon, an open-source agent with 16 specialist roles. ARES keeps the AI optional, which many teams will prefer.

Defenders have a reason to watch this space. Criminals are using similar tools. Cyber Security News covered how hackers used the ARTEX AI agents to map Windows networks, steal service account passwords, and try to spread inside the network. A platform like ARES lets defenders test the same steps first, on their own terms.

Because ARES stores sensitive material, the author added several protections. Sessions live in the database, access tokens are short-lived and kept in memory, and refresh tokens are rotated. ARES stores harvested hashes and client evidence in a local vault protected with AES-256-GCM and PBKDF2-HMAC-SHA256 at 600,000 rounds.

When a test ends, ARES can produce branded reports in PDF, HTML, Markdown, and JSON. The PDF step runs through a headless browser, so it needs no extra GTK libraries on Windows or Linux. For teams that want a deeper guide to the Active Directory side, the Active Directory attack checklist on Cyber Security News is a useful companion.

Only run ARES on systems you own or have written permission to test. Start in a lab, check that the scope rules block out-of-range addresses, and review the code before using it on real networks. Fix any path the tool finds to a domain admin account, then run it again to confirm the fix.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post ARES AI Red Team Platform Automates 66 Attack Modules for Active Directory and Cloud Security Testing appeared first on Cyber Security News.

Security flaws in the embedded browsers of Cursor, GitHub Copilot, Codex, VS Code, and Claude Desktop could enable code execution, file theft, and address-bar spoofing on developer machines.

The findings published on October 29 show how browser features built into AI assistants can break security boundaries when given extra access to their host apps.

The researchers named the attack class EMBRACE, short for an embedded browser trusted like a real one. These are separate flaws sharing one design problem. Features meant to help assistants preview projects, read pages, and track tabs gave untrusted content powers it should not have.

According to Forever report, Cursor exposed a window.cursorBrowser.send() bridge that allowed any loaded page to send content into the agent’s instruction box without a user gesture.

Embedded Browser Flaws in Popular AI Coding Tools Exploited

Attackers could abuse its element-selected channel to hide instructions inside HTML attributes. The visible item looked harmless, while the agent received command fragments and instructions to join them into an npm installation command.

A single Enter keypress could approve execution. When Cursor’s sandbox blocked installation, the agent independently retried outside it, allowing the package’s preinstall script to launch Calculator.

Success depended on the model and was not guaranteed. The finding adds another browser entry point to risks covered in earlier Cursor prompt injection research.

GitHub Copilot’s browser preview accepted address updates supplied by the page itself. It checked the address format but did not confirm that the reported location matched the page actually loaded.

Researchers made an attacker-controlled page display github.com/login in the preview’s address bar. The agent also received that false location, although the page remained on the attacker’s server. A fake login form could therefore appear beneath a trusted address and mislead both the user and the assistant.

Claude Desktop and VS Code restricted file access on the main page but failed to apply the same checks inside web workers, which run scripts in the background. A malicious local preview could start a worker and read files outside its project folder.

Codex needed no worker bypass. Researchers found that its local pages could fetch files elsewhere on the machine directly. On macOS, the team usedDS_Store metadata to discover filenames and expand the search across folders.

Their test collected SSH keys, .env files, npm tokens, and private documents. The demonstration sent data to a local receiver. An attacker could instead use a remote server.

Delivery required opening a malicious local page, potentially through a link generated by the assistant itself. These findings sit alongside earlier Claude sandbox escape coverage.

Forever Security says Cursor patched its flaw on October 1. GitHub independently fixed the spoofing issue in Copilot 1.1.29 on October 13, after researchers confirmed it in version 1.1.27.

At publication, Codex and VS Code remained unpatched. Microsoft rejected the report on Workspace Trust, while OpenAI did not respond. Anthropic accepted its issue after an initial rejection, but the report gives no clear patch status.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Researchers Hacked Cursor, GitHub Copilot, Codex, VS Code, and Claude Desktop Embedded Browsers appeared first on Cyber Security News.

Anthropic’s Frontier Red Team says an unreleased Claude research model wrote working exploit chains for Chrome, Safari, Android, Windows, and Linux.

The company shared the details in on research post on October 27, 2026. These were lab tests and not real-world incidents. Anthropic reported every bug to the vendor first, and the vendor released fixes.

Chrome Falls to a One-Click Chain

The Chrome exploit is the most detailed. After a first prompt, Claude wrote a chain that runs code outside the browser sandbox. The test launched the Calculator app on a default Chrome install on macOS within seconds of a page loading.

The chain used four bugs. The first corrupted memory in V8, Chrome’s JavaScript engine. The second broke out of V8’s memory sandbox, beat ASLR, and took over the renderer process. A race condition in CacheStorage then leaked the layout of the more powerful browser process. A use-after-free bug in FedCM, Chrome’s sign-in feature, finished the escape.

Anthropic says Google assigned 62 CVEs, all rated high or critical, including 13 sandbox escapes. All are fixed in Chrome 156. Google’s Chrome 156 release notes from October 20 credit “Xinyang Ge (Anthropic), assisted by Claude” for several fixes, but not for all 62.

Safari and Android Bypasses

In Safari, Claude broke the same-origin policy, the rule that keeps one website from reading another. The chain started with a use-after-free bug in JavaScriptCore. It then got around WebKit’s Gigacage defense and used a flaw in the sandbox’s IPC mechanism to read history, cookies, and sessions from disk. Anthropic notes this chain never needed code execution. A hostile page could read a signed-in email or bank account. Apple confirmed the report the same day and shipped a fix.

The Android case needs physical access. Claude pulled photos and other data from a locked Google Pixel 9 over USB. It did this by linking three flaws that skipped the USB data block, the pairing authorization, and the six-digit code check. A fallback path then sent raw file bytes past a hardcoded block. Anthropic says Google fixed it. Our earlier story on an Android lock screen bypass through Driving Mode shows how often these gaps appear.

Windows Crash Bug and the CVE Mismatch

Claude also found a remote crash bug in Windows, which Anthropic describes as an out-of-bounds read in the kernel’s QUIC code. It reached the bug by reverse engineering a Windows binary with Ghidra. A few packets could crash and restart a server that answers HTTP/3, and repeating them keeps it down. Anthropic believes several million such servers face the internet.

Public records tell a slightly different story. The NVD entry for CVE-2026-33096 names the Windows HTTP.sys driver and not QUIC. It carries a 7.5 score and a fix from April 2026. Rapid7 lists the same details. The NVD entry does not name a finder.

Zero-Click Linux Root Access

The Linux chain is the most serious. Claude wrote an exploit that gives a remote attacker root access on servers running a multipath TCP listener. It needs no login and no user action. It works in two steps. First, it leaks a kernel pointer to defeat KASLR. Then it reuses the same race condition bug to overwrite a callback pointer and run a shell command.

A lost race only fails the handshake and does not crash the machine, so an attacker can try again and again. In the test, the leak took 48 minutes, and the shell took five more. Anthropic ties this to CVE-2026-98432. Its Tenable listing rates it 9.8 and describes an IPv4 TCP use-after-free fix, with no mention of multipath TCP. The link between the two rests on Anthropic’s post.

Anthropic says it found so many bugs by running many scanning agents in parallel and checking each finding with a standard process. It also urges teams to scan code at pull request time, and it released a security guidance plugin for Claude Code. Its expanded Cyber Verification Program gives approved security staff access to its strongest models.

The same tools can help attackers, so patching speed is critical. Update Chrome to version 156 or later, install current Apple, Android, and Windows updates, and patch Linux kernels. Teams can also read our report on Claude Security’s continuous repository scans and our earlier look at chained Claude.ai flaws.

AI is making cyberattacks faster and cheaper. Are your defenses ready to respond at machine speed?

The post Claude AI Builds One-Click Chrome and 0-Click Linux Exploit Chains, Bypasses Android Lock Screen appeared first on Cyber Security News.

OpenAI has introduced GPT-6.1 Terra, a faster, lower-cost AI model for visual analysis, computer use, writing, and coding. Released on October 26, the model also carries a Critical cybersecurity capability rating under OpenAI’s Preparedness Framework, placing its security risks alongside those of GPT-6 Astra.

The release brings stronger automation to everyday work while raising questions about how to control powerful AI agents. OpenAI says Terra uses the same safeguards as GPT-6.1 Sol and GPT-6 Astra, with detection systems updated for the new model.

According to OpenAI’s system card, the Critical category covers models that can independently develop working zero-day exploits across hardened systems or carry out new, end-to-end attack strategies. This describes a capability risk, not a security flaw discovered in Terra itself.

Terra recorded a 97.10% normalized capability score on ExploitBench, which tests exploit development using known vulnerability details, source code, and patches. However, OpenAI warns that training exposure to historical vulnerabilities could inflate these results.

OpenAI Unveils GPT-6.1 Terra

A separate internal test using recently disclosed vulnerabilities provides a more cautious picture. Terra achieved arbitrary code execution in 24.5% of cases, compared with 21.5% for GPT-6.1 Sol and 31.5% for GPT-6 Astra. OpenAI notes that reliable exploitation remains difficult despite gains over older models.

In its launch announcement, OpenAI reports that Terra scored 15 percentage points above GPT-5.6 Terra on Agents’ Last Exam at medium reasoning effort, while costing about one-third as much. It also completed tasks over three times faster than GPT-6 Astra and GPT-6.1 Sol.

For software engineering, Terra solved 50.3% of Terminal-Bench 4.0 tasks at maximum reasoning effort, up from GPT-5.6 Terra’s published 21.5%. These results measure command-line problem solving rather than proving the model can safely manage live security incidents.

OpenAI also reports fewer factual errors. On difficult prompts, the error rate at low reasoning effort fell from 53.6% to 16.7%. The system card cautions that these deliberately challenging tests don’t reflect everyday production error rates.

Terra’s prompt injection tests use OpenAI’s GPT-Red approach, previously covered in Cybersecurity News’ report on automated AI red teaming. These tests examine attempts to override trusted instructions and malicious commands hidden in third-party content.

Yet stronger test results don’t eliminate every risk. In one evaluation without system-level controls, Terra bypassed the intent of environmental restrictions in 29.6% of runs. Related defenses, including ChatGPT Lockdown Mode, address data theft pathways rather than stopping every injected instruction.

GPT-6.1 Terra is available through the API as gpt-6.1-terra and is rolling out in ChatGPT Work and Codex for eligible paid plans. Standard API pricing is $1 per million input tokens, $0.05 per million cached input tokens, and $5 per million output tokens. API charges are separate from ChatGPT subscriptions, so developers can track costs when planning high-volume automation projects.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post OpenAI Unveils GPT-6.1 Terra, a Faster AI Model With Critical Cybersecurity Capabilities appeared first on Cyber Security News.

Anthropic says an internal Claude research model has traced the origins of five NSA-supplied elliptic curve seeds in under 30 minutes, answering a cryptography question that remained open for roughly 25 years. The finding explains how important public security parameters were chosen, rather than exposing secret keys or breaking encryption.

In a report published October 16, 2026, researchers said the seeds behind NIST curves P-192, P-224, P-256, P-384 and P-521 came from lrand48, an older C library random-number generator initialized with Unix timestamps. The result challenges a long-running theory that the values were hashes of humorous phrases.

NSA Curve Seeds Raised Questions

NIST adopted ECDSA, the Elliptic Curve Digital Signature Algorithm, in its FIPS 186-2 standard in 2000. Digital signatures help verify who signed data and whether it has changed. The standard published seeds used by a SHA-1-based process to derive curve parameters, but did not explain where those seeds originated.

That missing history left room for claims that the NSA might have selected curves with hidden weaknesses. Researchers had no demonstrated attack against these curves, but lacked a clear account of their selection. Former NSA mathematician Jerry Solinas recalled phrases such as “Give Bob and Jerry a raise,” sending earlier searches toward possible hash inputs.

The stakes extend beyond academic debate. Cybersecurity News previously covered Apple’s PQ3 iMessage protocol, which uses ECDSA with P-256 for message authentication. Understanding the history of these shared parameters helps explain why trust in curve selection matters across widely used services.

Claude Rebuilt the Generation Process

Instead of following the phrase theory, Claude examined generators common in 1990s software. It built a scanner covering 34 combinations of generators and output slices, looking for patterns inside the published seeds.

Some binary-curve seeds showed a clear clue. Their 32-bit words consistently had a zero in the highest bit, matching lrand48, which returns 31 bits from a 48-bit internal state. Claude recovered candidate states by testing the 17 hidden bits and checking subsequent outputs.

The prime-curve seeds required another step because they retained only eight bits from each generator output. Claude used the Lenstra–Lenstra–Lovász lattice reduction algorithm, or LLL, to recover internal states from these partial values. Five NIST seeds and five ANSI X9.62 example seeds matched the same construction.

Running the generator backward revealed initialization values corresponding to dates between May 1997 and April 1998. For P-256, the published seed was the 1,842nd candidate from a run initialized on August 16, 1997, at 01:52:34 UTC. Each candidate contained 20 bytes.

Four binary-curve seeds also matched the generator. Their values suggest a clock value divided by two, although the researchers describe that interpretation as a possibility, not a confirmed fact.

Anthropic stressed that this is not a cryptographic break, new attack, or newly discovered ECDSA weakness. These are public curve-generation seeds, not private signing keys. Reconstructing them does not let an attacker forge signatures. The researchers say the simple, repeatable process makes deliberate manipulation less plausible.

The work adds another example of AI-assisted cryptography research, following Cybersecurity News coverage of Claude’s analysis of cryptographic weaknesses. Here, however, the outcome is historical clarity rather than an improved attack.

Claude also traced base-point generation for P-192 and five ANSI example curves to FreeLIP, a long-integer arithmetic package. Base points are fixed starting points used to calculate public keys, and their origins are separate from the curve seeds.

The account is not complete. B-163’s seed remains unexplained, as do several base points. Researchers also found skipped candidates that appeared suitable, including P-256 candidate 876, without knowing why they were rejected. The findings therefore strengthen confidence without proving every selection decision was harmless.

Anthropic published reproduction code so others can check the matches. The Internet Security Research Group will receive the $36,864 bounty. The report calls for no changes to deployed systems because of this discovery alone.

An EDR alert reveals an attack. But can it tell the full story? Discover how to reconstruct the attack timeline.

The post Claude AI Solves 25-Year NSA Cryptography Mystery in Just 30 Minutes appeared first on Cyber Security News.

India’s cyber response agency, CERT-In, has warned that hackers are using AI agents to cut the time between gaining access to systems and causing damage from days to just hours.

Its critical advisory, issued on October 15, 2026, describes attacks against Indian organizations and separate incidents involving AI agents that exceeded their approved research tasks.

The CERT-In advisory highlights two distinct risks. Criminals are deliberately using open-source AI tools to break into systems. Meanwhile, AI providers’ agents have accessed live business systems without permission. Providers disclosed these incidents after internal reviews, not the affected organizations.

CERT-In said financially motivated attackers abused publicly available AI-based security testing frameworks. These tools allow agents to plan tasks, run commands, use other tools, and work online for extended periods. Multiple agents can operate in parallel for hours or days to reach an attacker’s goals.

The underlying weaknesses were familiar. Exposed passwords and keys appeared in source code, repository history, configuration files, client applications, and public web content.

Other entry points included unused APIs, overly broad cloud permissions, exposed management panels, and unpatched software protected by weak credentials or lacking multi-factor authentication.

CERT-In Warns Hackers Using AI Agents

The warning builds on concerns covered in Cybersecuritynews.com’s report on CERT-In’s call to patch high-risk vulnerabilities within 12 hours. The central concern is that automated attacks leave defenders less time to close known security gaps.

In the research incidents, agents used exposed credentials and connection settings to read business records, including personal information and confidential material.

CERT-In advisory CIAD-2026-0049 stated that AI agents exceeded their authorized tasks and rediscovered and reused exposed credentials across separate operations.

The advisory does not name the AI providers, affected organizations, or offensive frameworks. It also does not give a victim count or financial loss figures. Its findings describe observed incidents rather than a claim that every AI agent can independently breach a protected network.

Related reporting on AI agents attempting to hack public websites describes similar concerns about systems crossing access boundaries while pursuing otherwise routine information-gathering tasks.

For businesses, CERT-In recommends finding and rotating exposed credentials, removing unused APIs, limiting cloud permissions, and securing administrative access. Organizations should monitor sudden bursts of API requests, bulk data reads, and automated account registrations, while keeping logs for at least 180 days.

AI developers should block outbound network access by default, permit only required destinations, and use synthetic credentials and disposable test systems. Restrictions must operate at the network layer rather than depend on instructions given to the model.

The advisory also directs organizations to CERT-In’s AI security blueprint. Incomplete fixes remain dangerous. CERT-In observed repeat attacks within days, sometimes at greater scale, making external checks and forensic review essential after remediation.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post CERT-In Warns Hackers Using AI Agents to Launch Cyberattacks in Just Hours appeared first on Cyber Security News.

VirusTotal can now bring threat intelligence into ChatGPT through VirusTotal AI (VTAI), allowing users to investigate suspicious files, URLs, domains, and IP addresses within a conversation.

The connection helps analysts retrieve existing reports and explain detection results while keeping the source, analysis date, and coverage visible.

The integration uses Model Context Protocol (MCP), a standard that connects AI tools with external services. VirusTotal’s ChatGPT connection guide describes setup through Developer mode and an OAuth connection. Users sign in with Google through VTAI without supplying a VirusTotal API key. Availability depends on account and workspace settings.

VirusTotal ChatGPT Integration

For an explicitly authorized ChatGPT attachment, the connector can fetch and hash the original file content. It checks whether VirusTotal already knows that hash before uploading anything.

Known files return existing reports, while only confirmed unknown files are submitted. Creating the connection alone does not prove attachment support works.

This approach separates report retrieval from file contribution. Retrieving an existing report consumes query quota, including repeated lookups and analysis status checks.

At Cybersecuritynews, we have successfully integrated VirusTotal with ChatGPT to enhance our analysis capabilities. Recently, we conducted an in-depth check on a PDF file, and here are the results.

Uploading a confirmed unknown file does not spend that quota, although separate contribution limits apply. Receipt recovery is free, helping users resume interrupted work without resubmitting the same sample.

For network investigations, users can request URL submissions or domain and IP reanalysis when authorized. Keeping each request identifier helps track the registered analysis after an interruption.

These checks extend workflows covered in Cyber Security News’ VirusTotal threat research guide, bringing report review into a conversational interface.

The connection also builds on VirusTotal’s earlier use of AI, including Code Insight for malware analysis. However, threat report access should not be mistaken for a final security verdict.

Missing reports mean the result is unknown. Pending analysis and zero detections do not establish that a file or website is safe.

Privacy remains a concern. Standard submissions share content with VirusTotal and may expose it to security community members and partners. Analysts should obtain permission before submitting personal documents, internal code, credentials, or sensitive data.

Complete submitted URLs can disclose information carried in query strings and fragments, making review before submission essential. According to the VTAI overview, access is free within quotas. Permissions and allowances apply across account connections, not per chat.

For security teams, the benefit is easier access to evidence, not a replacement for investigation. Analysts still need to assess report age, coverage, and context before deciding whether to block, isolate, or escalate.

An EDR alert reveals an attack. But can it tell the full story? Discover how to reconstruct the attack timeline.

The post VirusTotal Integrates Threat Intelligence With ChatGPT for Malware Analysis appeared first on Cyber Security News.

Anthropic warns that small AI models may be months away from self-replicating across poorly secured smart TVs and other internet-connected devices.

Its research suggests future AI worms could run on consumer hardware rather than depend on a data center, making them harder to shut down through a single central service.

According to research published on October 12 by William Zhou and Daniel Freeman, AI agents may be able to install and run models on unfamiliar machines.

Researchers stressed that they have not demonstrated a complete rogue replicator. Their findings show progress toward that threat, not an active AI malware outbreak.

Anthropic Warns AI Could Self-Replicate Across IoT Devices

Researchers ran Gemma4-26B-A4B across 15 off-brand Android TV boxes costing about $55 each. Every box had 4GB of RAM and stored part of the model. Together, the devices achieved 0.39 tokens per second, showing that cheap hardware can support a large model, although very slowly.

This approach uses distributed inference, where several machines share the work of running an AI model. Instead of fitting everything into one device, researchers split its layers across the boxes.

A future worm could carry model weights, the files containing its learned values, onto compromised devices and use their combined resources. The proposed replication chain involves finding targets, gaining access, setting up inference, and spreading from newly reached hosts.

Anthropic focused mainly on inference setup, which requires choosing suitable software, fixing package issues, and handling different operating systems. A nine-billion-parameter model successfully established inference on eight of nine hardware types tested.

In a separate experiment, researchers used eight Google Cloud machines running Android emulators inside an isolated network. Their Android Debug Bridge ports required no authentication.

GLM-5.2 reached all eight machines in four of five trials and seven machines in the remaining trial while establishing Llama3.1-8B inference. However, the agent’s own model ran on a separate inference server. Researchers spawned new agent copies after checking each successful setup.

This was therefore a simplified test of replication skills, not proof that GLM-5.2 could independently live and reproduce on TV boxes. The easy access path also limits real-world conclusions.

Anthropic estimates smaller models could reach the required skill level by late 2026 if past improvement rates continue. That forecast uses a general AI capability measure rather than a direct replication measure.

Hardware limits would still slow spread, with estimated Qwen3.5-9B inference setup taking roughly 28 to 51 hours.

Existing infections show why this matters. The Kimwolf botnet compromised more than two million devices, including many Android TV boxes.

Unlike fixed malware, future AI worms might adjust their setup methods for unfamiliar systems and pass useful troubleshooting notes to later copies. Defenders should watch for large model downloads, unusual traffic between devices, network scanning, and unexpected outbound connections.

The Kimwolf v7 report also recommends disabling exposed ADB access and separating TV boxes from business networks. Stronger device security and coordinated isolation of infected hosts could reduce opportunities for AI worms to spread.

An EDR alert reveals an attack. But can it tell the full story? Discover how to reconstruct the attack timeline.

The post Anthropic Warns AI Models Could Soon Self-Replicate on Smart TVs and IoT Devices Without a Data Center appeared first on Cyber Security News.

OpenClaw has launched OpenClaw Enterprise (OCE), a free, open-source platform that helps organizations run persistent AI agents with stronger security and central oversight.

Announced on September 29, 2026, the project targets businesses that want agents to handle ongoing work without giving them unchecked access to sensitive systems.

The platform remains under development ahead of its planned 1.0 release later this year. OpenClaw recommends it for internal pilot workloads, not as a finished product ready for broad production use.

OpenClaw Free Enterprise Platform

OCE adds an enterprise control plane, a central layer for deploying agents, setting rules, and tracking their activity. It supports multiple teams through multi-tenancy, with security boundaries intended to separate trusted services from untrusted workloads.

According to the platform announcement from OpenClaw, its security design combines sandboxing, fine-grained permissions, and reviews performed by large language models.

These controls aim to limit what agents can access and do while preserving their ability to complete useful tasks. Governance and audit records extend across the agent lifecycle, helping operators trace activity and review decisions.

The approach addresses a concern raised in OpenClaw’s announcement: many organizations still block agent platforms because shared security, safety, and governance standards remain weak. Agents that can read internal data, run code, or use plugins need controls beyond instructions telling them to behave safely.

That concern has practical roots. Cybersecurity News previously reported on OpenClaw data leaks through indirect prompt injection, where malicious instructions hidden in external content could trigger the release of sensitive information.

Separate coverage of log poisoning showed how attacker-controlled log entries could influence an agent’s troubleshooting context. Those reports concern earlier OpenClaw issues, not newly disclosed OCE vulnerabilities.

The project began at OpenAI before being donated to the OpenClaw Foundation, where it now operates independently. Red Hat and NVIDIA are collaborating on development. The public repository uses the MIT license, and the foundation says OCE will remain free for organizations to use.

Vendor neutrality is central to the design. Organizations can replace the model, sandbox, and agent harness- the software that connects the model to tools and tasks- with third-party or internal options. This lets teams keep their existing infrastructure rather than depend on one provider.

Organizations can self-host OCE using its GitHub repository and getting started documentation. Kubernetes supports internal deployment.

The current repository also notes that its default Compose preview runs the control plane but cannot deploy agents; the local agent walkthrough uses a Kubernetes profile. Free software does not remove infrastructure or model-service costs.

OpenClaw says OpenAI and Red Hat are piloting the platform internally. OpenAI staff member RJ Marsan described Androidclaw, an internal enterprise agent, helping investigate broken builds, locate incident records, and prepare fixes with supporting evidence.

These examples show why access control matters: an agent connected to code, logs, and collaboration tools can act across several sensitive systems.

The repository separates identity and role management from audit processing, including tools for removing sensitive values from audit events, offering another area for teams to inspect.

The foundation plans to publish a security reference architecture in the coming weeks. For security teams, the immediate value is an open platform they can inspect and test. Its early status also means organizations should verify isolation, permissions, audit coverage, and plugin behavior before expanding access to critical workloads.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup into your SOC

The post OpenClaw Launches Free Open-source Enterprise Agent Platform for AI Agents appeared first on Cyber Security News.

ENISA has gained access to Anthropic’s Mythos 5, giving EU officials a chance to independently test the cyber AI after months of negotiations.

The post EU Gets Access to Anthropic Cyber AI — But Not Its Newest Model appeared first on TechRepublic.