Placeholder third-party[.]com Referenced Across 1,700+ Repositories Now Serves Malicious Content

The "third-party[.]com" domain, commonly used as a documentation placeholder, has been observed serving a ClickFix lure to Windows browsers while displaying a harmless decoy to other users.

"third-party[.]com has been a generic documentation placeholder for years, the same role example.com plays," Manifold Security's Head of Research, Ax Sharma, said. "Unlike 'example[.]com,' third-party[.]com is not IANA-reserved. Anyone could register it, and someone did. Every doc, test, and skill that hard-coded it now points readers at attacker infrastructure."

As of writing, the domain has been marked as malicious and unsafe on both VirusTotal and Google's Safe Browsing list.

ClickFix is a social engineering attack technique in which either malicious or legitimate-but-compromised websites display error messages, browser alerts, or CAPTCHA verification prompts, tricking users into copying and executing hidden commands via the Windows Run dialog or Terminal to "fix" the issue.

Often, web pages using ClickFix rely on clipboard hijacking to automatically inject malicious script or commands into the victim's clipboard for subsequent pasting on Windows Run dialog or macOS Terminal. This approach is also sometimes referred to as pastejacking.

According to Manifold Security, the domain has been serving the ClickFix lure since at least June 2026. Windows users visiting the page are shown a Cloudflare check that poisons the victim's clipboard and instructs them to paste and run the command via the Windows Run dialog. The pasted command is designed to extract and run a remote PowerShell payload.

When a macOS user visits the same page, the fake security verification prompt shows an error: "macOS is not supported. This website requires a Windows PC to access. Please try again from a Windows device."

A search on GitHub shows that the domain is referenced in over 1,700 public repositories, including those related to AI agent skills and MCP-server docs that cite "third-party[.]com" as an example endpoint.

"In every one of those places it is exactly what it looks like: a placeholder, an example, a stand-in, and entirely reasonable use by the teams involved," Sharma noted. "It is also, now, a live pointer to a ClickFix server."

This weaponization of a blindly trusted domain, in turn, can open up avenues for prompt injection and other unintended behaviors.

To counter the threat, it's advised to audit their documentation and treat non-reserved placeholder domains (e.g., yourcompany[.]com, mycompany[.]com, your-api[.]com, and their lookalikes) as squattable and open to abuse by threat actors, who can register them and serve malicious content.

Developers working on skills, documentation, or test cases are recommended to use reserved placeholders like "example[.]com" (or "example[.]org," "example[.]net") only and avoid using plausible-sounding domains that are not under their control.

"You can scan the skill, read the file, resolve the domain from your analysis box, and conclude it is fine, and be completely wrong about what a Windows user's agent receives when it follows the same link," Manifold Security pointed out. "A file scan cannot see what a website decides to send. The tell only appears at request time, from the caller that matters."

The disclosure comes as Manifold said it has since identified 13 more placeholder domains that are not IANA-reserved, with two of them – yoursite[.]com and your-domain[.]com – serving scams and scareware to macOS visitors and an ordinary parking page to other users.

"On a macOS browser, your-domain[.]com showed a fake 'MacOS Security Center' claiming four viruses and selling a counterfeit McAfee renewal at 55% off," security researcher Cody Nash said. "On another macOS render, yoursite[.]com showed a counterfeit ZDF news article advertising an investment scheme."

The complete list of domains, each of them are pass static checks, is as follows -

• your-domain[.]com
• yourdomain[.]com
• your-site[.]com
• yoursite[.]com
• your-app[.]com
• yourapp[.]com
• myapp[.]com
• mysite[.]com
• acme[.]com
• company[.]com
• mycompany[.]com
• vendor[.]com
• foo[.]com

To make matters worse, the two scam-scarware-serving sites are present in hundreds of thousands of GitHub files and hundreds of agent skills. "Scareware and investment fraud are a lower threat than clipboard malware, the exposure they ride on is far larger, and none of it showed up in any static check we ran," Nash said.

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

Hacked Ukrainian Sites Serve Fake Cloudflare ClickFix Lures for Psychedelic Stealer

An active ClickFix campaign has been observed compromising legitimate Ukrainian business websites to inject bogus Cloudflare verification pages and trick victims into downloading a previously undocumented information stealer called Psychedelic.

"When a visitor interacts with the page, the lure copies a Windows Installer command to the clipboard and instructs the visitor to paste it into the Windows Run dialog," Arctic Wolf Labs said in a technical report shared with The Hacker News.

The ClickFix chain uses an "msiexec.exe" command to fetch a Windows MSI installer that's used to deliver the stealer malware. The malicious tool is designed to harvest browser passwords, account tokens, and cryptocurrency-wallet data, set up scheduled-task persistence, and contact a command-and-control (C2) server for additional tasking.

Some of the compromised websites include a hair-treatment clinic, a scale-model manufacturer, a specialist bookseller and publisher, a psychological facility, a tool retailer, and an automotive retailer. These affected sites include an injected iframe element that's responsible for executing attacker-controlled JavaScript ("fsputnik[.]com/tds/tracker[.]js").

The ClickFix command, for its part, retrieves an MSI installer ("elita.msi") hosted on "uasputnik[.]com," a domain that was registered on September 9, 2026. Other MSI payloads identified include "miks.msi," "astra.msi," "harbor.msi

," "neon.msi," "sova.msi," and "vyse.msi."

"The attacker-controlled page imitates a Cloudflare verification screen and presents Ukrainian-language instructions," Arctic Wolf said. "The clipboard operation occurs before the lure displays its Windows Run instructions. After a three-second spinner, the page presents an instruction dialog and keeps the 'Done' button disabled for approximately 35 additional seconds."

"This delay controls progression through the lure interface; it does not verify that the visitor opened Windows Run, pasted the command, or installed the payload."

The MSI installer, for its part, is responsible for retrieving the next-stage payload ("psychedeliclove.exe") from the URL "107.175.82[.]242:9000." The 64-bit Windows executable is Psychedelic Stealer, which performs the following functions -

• Collect credentials from Chromium-based browsers, including Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, and Yandex, and exfiltrate them through the "/api/v1/ext/passwords" endpoint
• Collect browser-associated account tokens and exfiltrate them through the "/api/v1/ext/tokens" endpoint
• Scan for known cryptocurrency wallet browser extensions (MetaMask, Trust Wallet, OKX Wallet, and SafePal) and desktop apps (Exodus, Atomic Wallet, Electrum, Bitcoin Core, and Litecoin Core) and exfiltrate data through the "/api/v1/ext/wallets" endpoint
• Capture extensive host information and exfiltrate it through the "/api/v1/checkin" endpoint
• Terminate selected browser processes, extract an embedded extension archive into web browser profiles, and set a native-messaging bridge

"These components extend the operation beyond one-time data collection," Arctic Wolf said. "Browser-profile modification and native messaging provide a mechanism for deployed browser content to communicate with a local host component."

"A recurring background routine revisits extension-related operations before polling the C2 server for tasks, indicating that browser-component handling is integrated into the implant's ongoing execution cycle rather than limited to initial installation."

Psychedelic Stealer also features the ability to retrieve further tasks using the "/api/v1/agent/tasks?hwid=%s" endpoint, where "hwid" refers to a unique victim identifier. It can allow the malware to run EXE, COM, BAT, CMD, MSI, and PowerShell payloads, offering the operator a way to introduce additional malware.

Arctic Wolf said it identified an exposed lure management panel linked to the campaign called РУБЛЁВКА TDS (Rublevka TDS) on the "uasputnik[.]com" domain. The panel, which is distinct from the implant's C2 ("193.178.159[.]128:8080"), is used to configure web-lure commands and records interactions.

"The dashboard polls visitor records every two seconds, providing near-real-time visibility into progression through the lure interface, not endpoint execution," it added.

At the time of analysis, the panel recorded 557 views, 426 clicks, and 79 complete events across 32 countries, with Ukraine accounting for 446 views, 351 clicks, and 71 complete events. Other targets include the U.S., Poland, Germany, Canada, and the Netherlands.

"Russian-language branding and implementation artifacts suggest likely Russian operators, and the intended audience is clear: Ukrainian-language instructions, affected Ukrainian business websites, and the panel's concentration of recorded views in Ukraine support an assessment that the campaign focused heavily on Ukrainian users," the cybersecurity company concluded.

ClickFix Delivers RemotePanel and BoundSiphon

The development comes as Blackpoint Cyber said it identified two undocumented .NET malware components delivered together via a ClickFix chain: RemotePanel, a persistent remote access platform, and BoundSiphon, a .NET credential and cryptocurrency stealer that targets both Chromium and Firefox browsers.

"RemotePanel establishes persistence by masquerading as the Windows Time service and gives operators broad control over infected systems, including PowerShell, file and process management, screen access, modular HVNC, and fleet management," researchers Nevan Beal, Sam Decker, and Andi Ursry said.

"BoundSiphon runs primarily from memory and targets browser credentials and sessions, cryptocurrency wallets, password manager data, and selected documents, including secrets protected by Chromium App-Bound Encryption."

RemotePanel makes use of a BNB Smart Chain contract to resolve its C2 server, thereby allowing the threat actors to rotate infrastructure without rebuilding or redeploying the malware on infected hosts. BoundSiphon, on the other hand, is assessed to share overlaps with a stealer that was flagged as being distributed via five malicious NuGet packages back in May 2026.

The attack sequence begins with a ClickFix command that uses PowerShell to initiate a multi-stage chain, with one of the intermediate components abusing the CMSTPLUA COM object to bypass User Account Control (UAC) and gain elevated administrative privileges without prompting the user and run a privileged hidden PowerShell process.

The process then proceeds to configure broad Microsoft Defender exclusions and fetch and execute two additional payloads using different methods -

• RemotePanel, which is written to disk, installed as a service, and is used for persistent remote access and operator control through interactive PowerShell sessions, file and process management, screen streaming, and modular hidden virtual network computing (hVNC)
• BoundSiphon, which is loaded directly into memory through PowerShell, and is used for credential, session, wallet, and document collection

The campaign has not been attributed to any known threat actor or group, although Blackpoint said it recovered artifacts that suggest a possible Russian-speaking development environment. This includes source code checks to avoid executing on systems with a Russian keyboard layout.

"RemotePanel and BoundSiphon reflect a broader shift toward modular malware ecosystems that separate persistent access from data theft, allowing operators to replace infrastructure and individual components while retaining the underlying capabilities needed to continue an operation," Blackpoint said.

"RemotePanel can move its backend through an owner-controlled BNB Smart Chain resolver without rebuilding the implant, while BoundSiphon moves its App Bound Encryption recovery into legitimate Chromium processes to reach newer browser secrets."

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

Proactive Defense: Hardening Code Pipelines and CI/CD Infrastructure

Introduction

The landscape of software supply chain security has undergone a significant shift. Recent campaigns demonstrate that sophisticated threat actors are systematically targeting the engineering lifecycle by compromising trusted security and programming tools.

These intrusions reveal three key tactics:

• Attackers target trusted security scanners, utility libraries, and AI developer tools to exploit the elevated privileges granted to these systems within build pipelines.

• Adversaries target developer workstations and Integrated Development Environments (IDEs) via highly tailored social engineering, malicious extensions, or typosquatted local dependencies to exfiltrate private cryptographic keys, API tokens, and active session credentials directly from local engineering environments.

• Rather than relying solely on compromised static credentials, attackers have escalated to advanced pipeline manipulation techniques, including GitHub Actions cache poisoning, OpenID Connect (OIDC) token extraction, and the subversion of mutable action tags to publish compromised packages that still carry legitimate cryptographic provenance.

Building upon prior guidance (here, and here), this blog provides an actionable blueprint for software and platform architects designed to safeguard the software supply chain against threat vectors that are actively being exploited, third-party risks, and architectural vulnerabilities throughout the entire Software Development Lifecycle (SDLC).  

Read on for more on how to establish continuous integration and continuous delivery/deployment (CI/CD) safeguards, strengthen developer workflows, and build robust, end-to-end defense-in-depth. 

The Multi-Layered Approach

Treating each stage of the pipeline as independent security domains is no longer sufficient because these multi-layered attacks target vulnerabilities across the entire build pipeline. Defending against these persistent threats requires a thorough, defense-in-depth approach spanning the five key pillars of the software development lifecycle outlined in Figure 1:

Figure 1: The five core pillars for securing the software development lifecycle

Endpoint 

Developer workstations are high-value targets because they hold direct, privileged access to repositories, pipelines, and cloud environments. Threat actors frequently target IDEs, exploiting unmonitored local access to collect personal access tokens (PATs), SSH keys, and proprietary code. Organizations should establish a unified security layer that enforces a consistent security posture across all local host machines and cloud-based development environments.

Local Secret Scanning 

Organizations should deploy pre-commit hooks and IDE-integrated scanning tools to detect and block secrets prior to repository commit. Standardizing local pre-commit templates ensures git trees are fully verified before changes are pushed to central servers. To minimize the impact of a potential leak, organizations should migrate from legacy classic PATs to fine-grained PATs constrained by tight time-to-live (TTL) limits and minimal, environment-specific permissions.

Endpoint Security Management

Organizations should configure Endpoint Detection and Response (EDR) solutions to monitor developer software integrations and enforce continuous device posture checks. EDR agents should monitor trusted IDE process trees for anomalous file access, unexpected process spawning, and unauthorized outbound network connections. 

To ensure complete alignment, these EDR compliance signals should be integrated directly with Unified Endpoint Management (UEM) systems to automatically restrict or revoke a user's ability to access Source Code Management (SCM) systems, execute pipeline tasks, or publish code if their device falls out of compliance. Necessary command-line interface (CLI) process exclusions should be strictly restricted to designated, isolated developer environments rather than applied broadly across corporate endpoints.

IDE Standardization

Organizations should vet and approve specific versions of IDEs, browser integrations, and third-party extensions. IDE and browser marketplaces should be restricted to allow only vetted applications, explicitly blocking unverified extensions. All integrations require a formal third-party risk management review before allowlisting. Organizations should maintain an active software asset inventory paired with strict version-pinning and centralized emergency-block capabilities to stop newly discovered threats.

AI-Assisted Security

Engineering teams should leverage only approved large language models (LLMs) and AI agents for pre-merge vulnerability analysis and application security testing. This boundary is critical, as threat actors have begun actively inserting malicious code into open-source Model Context Protocol (MCP) packages and tricking AI coding agents (as detailed in our accompanying blog).

To mitigate risks like context poisoning and data exfiltration, security teams should deploy context-protection tools to validate inputs before runtime execution. Developers should, wherever possible, exclude local environment (.env) files from the workspace using platform-specific ignore configurations to prevent sensitive credentials from entering the model's context window. Organizations should maintain a human-in-the-loop control model to verify all AI-generated code before it is written to a  repository.

Isolated Developer Sandboxes

To prevent host-level compromises, organizations should, wherever possible, require the use of containerized development environments or dedicated virtual machines (VMs). Sandboxing ensures malicious post-install scripts or dependency-poisoning attacks cannot traverse the local filesystem.

Mounting sensitive host paths into workspace containers should be restricted to prevent compromised dependencies from executing with host privileges. Developer guest VMs should be instantiated from centralized, hardened golden images and network isolated from live production environments. All sandbox execution and network activity should integrate into centralized corporate logging.

Code Repositories  

Source code repositories serve as the definitive source of truth for an organization's proprietary software and intellectual property. Hardening this layer requires control over user identities, strict branch governance, and continuous verification of the code history to prevent unauthorized changes from entering the lifecycle.

Universal Identity

Securing repositories requires strict control over user identities. Implementing a Company Managed User (CMU) model allows organizations to retain full ownership of all accounts, including outside collaborators, and enables the enforcement of phishing-resistant multi-factor authentication (MFA), such as FIDO2 compliant physical security keys or digital passkeys.

However, CMU accounts may be inhibited from contributing to external, open-source repositories. Because of this limitation, a standard user model with MFA enforced Single sign-on (SSO) integration remains the recommended approach for teams engaged in public or open-source publishing and private collaboration.

Regardless of the chosen account model, identity verification should be continuous. Organizations should deploy conditional access policies to verify device posture before granting access, while monitoring user API activity to quickly detect compromised sessions.

Branch Protection

Organizations should implement a zero direct-to-main policy, ensuring all changes flow through isolated feature branches that require peer reviews and pass automated CI checks before merging. Administrative bypass policies should be disabled. At the filesystem level, force-push activity should be restricted and monitored. Security teams should continuously analyze audit histories for chronological discrepancies to identify timeline tampering and detect unauthorized dead-drop repositories used for code exfiltration.

Credential Lifecycle

To prevent long-term persistence, organizations should automate credential rotation, implement just-in-time retrieval mechanisms, and establish a strict token TTL. For developer access, organizations should deprecate PATs which function essentially as static, host-stored passwords vulnerable to local infostealer malware and transition to cryptographically verified SSH-based authentication backed by hardware security keys (such as FIDO2/YubiKey or macOS Secure Enclave).

For automated CI/CD pipelines and third-party integrations, organizations should mandate the use of GitHub Apps in place of service account PATs to leverage short-lived, highly scoped access tokens that automatically expire after one hour. Secrets should not be stored in environment variables; local environment files (.env) should be excluded via .gitignore while utilizing native platform secret features for runtime injection.

Dependency Security

For application manifests utilizing Semantic Versioning (SemVer), organizations should prohibit dynamic version ranges (such as carets ^, tildes ~, or wildcard * operators) that introduce dependency drift during resolution. Instead, configurations should mandate exact SemVer pinning (e.g., 1.4.2) supported by strictly enforced, cryptographically verified lockfiles

Unverified execution vectors, such as blind "curl to bash" scripts, should be blocked in favor of direct vendor containers invoked via explicit SHA-256 digests. Organizations should implement Software Composition Analysis (SCA) paired with reachability analysis to prioritize patching vulnerabilities that are actually executed within the application path. Builds should generate a software bill of materials (SBOM) and enforce Supply-chain Levels for Software Artifacts (SLSA) Level 2+ provenance checks.

Artifact Management 

Defending the artifact layer requires controlling what crosses the boundary into the trusted build environment. Point-in-time scanning is no longer sufficient; organizations should continuously inspect and verify upstream components before they propagate downstream.

Dependency Cooldowns

Organizations should mandate a minimum release-age cooldown of seven days before any newly published public package version becomes installable. Community detection often identifies and removes malicious open-source packages shortly after they are published.

Establishing a strict seven-day buffer provides the open-source ecosystem time to detect and pull poisoned releases before they reach internal builds. This delay should be enforced at centralized registries or local configurations; for specific configuration parameters (such as configuring npm's minimumReleaseAge cooldown or secure Python pip indexing), see the technical implementation steps detailed in our accompanying blog.

Proxies & Quarantines

All external packages and container images should, wherever possible, route through a centralized internal proxy that caches, inspects, and gates each component. Organizations can manage this secure boundary using Google Artifact Registry to host private repositories, configure virtual upstream repositories, and restrict direct build-runner access to public registries. New components arriving through the proxy should be held in a quarantine state and screened, blocking builds automatically on a failed security verdict. Internal repositories should be kept distinct from public registries to prevent dependency confusion attacks, and promotion to the trusted registry should follow a deliberate, policy-driven approval path.

Vulnerability Scanning

Container images and third-party dependencies should undergo automated scanning at the registry layer and at runtime. Stored artifacts should be continuously re-evaluated as new vulnerabilities emerge. To manage alert volume, results should be prioritized using reachability analysis and real-world exploitation signals, such as the CISA Known Exploited Vulnerabilities (KEV) catalog. Vulnerability Exploitability eXchange (VEX) statements should be used to suppress inapplicable findings and reduce noise.

Image Provenance

Verifying that an artifact came from a trusted source is as critical as confirming it is free of known vulnerabilities. Provenance establishes this trust by cryptographically signing every internally produced container image and package, then binding each one to the specific build workflow and source commit that created it. Modern signing tooling makes this practical without the burden of managing long-lived signing keys, instead tying each signing event to a build identity and recording it in a public transparency log. A signature is only meaningful when checked, so verification should be enforced at admission, restricted to the exact build identity expected, and performed against an artifact's immutable digest rather than a mutable tag.

The same principle extends to the credentials that publish artifacts. Long-lived registry published tokens are a recurring root cause in supply chain incidents, since a stolen token lets an attacker publish poisoned versions under a trusted name. Where possible, these static tokens should be replaced with short-lived, identity-bound publishing tokens issued to a specific build workflow at the moment of release. For first-party builds, adopting a recognized provenance standard provides a consistent benchmark for how and where software was built.

SHA Referencing

Container image tags and action references are mutable by default, which means an upstream actor can silently replace the content behind a trusted name at any time. Pinning to an immutable cryptographic digest closes this gap, because a digest is a content hash and any change to the underlying artifact produces a different identifier, breaking the reference rather than substituting malicious content under a name the pipeline already trusts.

Images should be pinned by digest, and third-party actions should be pinned to a full commit hash rather than a version that can be repointed. This discipline should extend across every image a build touches, not just the primary application image, since base images, sidecars, and init containers are equally viable injection points if left on mutable tags. Teams should also avoid configurations that re-resolve a mutable tag on every restart in production.

CI/CD

Hardening the automated pipelines within CI/CD infrastructure is a critical requirement for securing the broader software development lifecycle. Because these environments rely on an extensive web of privileged integrations to access source repositories, third-party registries, and cloud infrastructure, they function as high-value targets for adversaries. Securing these build and delivery systems requires the rigorous application of least-privilege principles, the enforcement of strict network boundaries, and the continuous verification of every trusted software component.

Runner & Build Servers

Hardening CI/CD infrastructure is a critical task because these pipelines require access to code repositories, dependency registries, and cloud environments. To secure these integrations, the primary defensive objective is to eliminate runner persistence. Organizations should use ephemeral, single-use runners, ensuring that every job executes in a fresh, isolated environment that is automatically destroyed upon completion. This clean-slate approach prevents cross-job contamination and denies attackers a permanent foothold. For self-hosted environments, this isolation should extend to the network layer, restricting outbound runner traffic exclusively to pre-approved registries and repository APIs to prevent data exfiltration. Furthermore, to mitigate Poisoned Pipeline Execution (PPE), the execution engine should block unvetted code from pull requests from accessing secrets or triggering deployment-grade runners until an administrator grants manual approval.

Additionally, pipelines should protect shared build caches from tampering. Because build caches are frequently shared across branches to speed up builds, a malicious pull request can inject corrupted dependencies directly into the shared cache. If left unrestricted, a subsequent production build will retrieve this poisoned cache and run the malicious code in a trusted environment. Pipeline setups should isolate cache access strictly by branch privilege and reject cache writes from unauthenticated forks.

Least Privilege CI/CD

• Federated Ephemeral Identities: Prohibit persistent automation secrets within workflows, leveraging OIDC to exchange pipeline identities for short-lived tokens.

• Zero-Trust Execution Scopes: Issue read-only or null-permission runner identities by default, requiring components to explicitly request minimum viable permissions.

• Shared State Parameterization: Prohibit the automatic inheritance of credentials across downstream templates or nested workflows to isolate sensitive variables.

• Runtime Governance: Restrict unsanctioned third-party plugins and marketplace actions. Security teams should also sandbox or disable package installation lifecycle scripts (using configurations like ignore-scripts=true detailed in our accompanying blog) to prevent compromised dependencies from executing arbitrary commands in build environments.

• Environment Isolation: Segment network and IAM boundaries so that early-stage validation or linting tasks operate completely decoupled from systems possessing release authority.

• Immutable Branch History: Disable history-rewriting functions and force-pushing on canonical branches to maintain an append-only audit trail.

• IaC Validation: Scan Infrastructure-as-Code (IaC) prior to deployment to block over-privileged keys, unquoted user-parameter injections, unencrypted webhooks, and runner RBAC misconfigurations.

Scanning Gates & Attestation

CI/CD scanning gates act as automated quality control within the deployment process, evaluating code against set security standards and automatically halting deployments if the defined criteria are not met. Placing scanning gates as early in the process as possible alerts developers of potential vulnerabilities before they reach production:

Secret Scanning (At the Developer Commit / PR Gate): Configure pre-commit hooks and SCM-level scanners to block developer pushes if they contain hardcoded API keys, passwords, or SSH keys. This stops secrets from ever entering your repository's permanent history.

SAST - Static Application Security Testing (At the Pull Request / Peer Review Gate): Integrate SAST into your continuous integration (CI) tests to analyze draft code before it is merged into the main branch. This automatically flags structural flaws, logic vulnerabilities, or dangerous functions (like unescaped user inputs) during active development.

SCA - Software Composition Analysis (During the Build Phase): Trigger SCA scans when your build environment resolves dependencies. By scanning your package lockfiles (e.g., package-lock.json or requirements.txt) against databases like Google OSV, you can automatically fail builds that attempt to import libraries with active, known CVEs.

Container/Image Scanning (At the Registry / Push Gate): Build automated scanners directly into your container registry pipeline. Before a newly built container image is allowlisted for production, the registry scanner should inspect its base OS packages and reject any image containing critical OS-level vulnerabilities or default root access.

DAST - Dynamic Application Security Testing (In Staging / Pre-Deployment): Create a temporary, isolated staging instance of your running application as a deployment step. Run automated DAST tests to simulate real-world attacks (like SQL injection or cross-site scripting) against your endpoints, validating that your active runtime defense configurations are working.

CSPM - Cloud Security Posture Management (Pre-Deployment IaC Scan & Post-Deploy): Use Policy-as-Code tools to scan your Infrastructure-as-Code (IaC) templates (like Terraform or Kubernetes manifests) before applying changes. This automatically blocks the provisioning of misconfigured cloud environments, such as overprivileged IAM roles or security groups with SSH (port 22) open to the internet.

SBOM Generation and Attestation

An SBOM is a complete, verifiable inventory of every component that went into a build. Generating and signing the SBOM as part of the build produces this inventory as a tamper-evident attestation rather than an after-the-fact reconstruction.

In practice, this means generating the SBOM as a build step in a recognized format such as CycloneDX or SPDX. The resulting SBOM should be signed as an attestation tied to the artifact’s digest, preventing modifications. Signed SBOMs should then be mapped back to affected artifacts without re-scanning every image in the fleet. To keep monitoring useful, VEX statements should be used to flag findings that do not apply to the code, ensuring the inventory remains an actionable triage tool.

Deployment

Securing the runtime phase ensures that workloads remain protected even if an attacker manages to bypass early pipeline defenses. This operational layer acts as the final quality gate as code transitions from the build pipeline to active production.

Workload Protection & Runtime Hardening

Workload protection should be enforced directly on running applications and container instances to limit their execution footprint and block active exploits.

• Deployment Guardrails: Establish an automated security check at the entrance of your production environment to block any container that lacks a valid cryptographic signature, requests unneeded root privileges, or originates from an untrusted public registry.

• Workload Posture: Build workloads from hardened base images and run them on immutable infrastructure with read-only root filesystems and removed SSH capabilities to prevent post-exploit file creation or lateral directory traversal.

• Active Application Protection: Deploy Runtime Application Self-Protection (RASP) to block execution-level exploitation attempts like SQL injection. Protect AI workloads from prompt injection and jailbreaks using runtime guardrails such as Google Model Armor.

• Just-In-Time Access: Eliminate standing administrative privileges in favor of time-bound, task-scoped access credentials that expire automatically, injecting privileged credentials at runtime only when required.

Protecting Live Infrastructure

Securing the surrounding network and cloud control plane shields your deployed applications from external threats, blocks lateral movement, and maintains the absolute integrity of your cloud configuration.

• Web Application Firewalls (WAF): Deploy edge firewalls to inspect incoming application-layer traffic, filtering out malicious payloads and blocking common web exploits, such as cross-site scripting or OWASP Top 10 vulnerabilities, before they reach your backend services.

• API Gateways and Load Balancers: Centralize edge authentication, enforce rate limits, and validate request signatures to prevent direct public exposure of application backends.

• Microsegmentation: Enforce granular, identity-aware network policies to isolate workloads and restrict traffic exclusively to pre-authorized service-to-service communication paths, blocking lateral network movement by default.

• Configuration Integrity: Deploy Policy-as-Code tooling to continuously validate the live environment against the version-controlled IaC source of truth, automatically reverting out-of-band modifications to prevent unauthorized changes.

• Active Posture Scanning: Run Cloud Security Posture Management (CSPM) and Cloud Native Application Protection Platforms (CNAPP) to continuously scan for cloud misconfigurations, overly permissive IAM, and exposed storage.

• Continuous Monitoring: Maintain complete visibility across all systems by collecting logs, system metrics, and audit events to quickly detect, trace, and respond to live security events.

Conclusion 

Recent software supply chain campaigns demonstrate that development infrastructure, build pipelines, and developer utilities represent critical threat vectors and key points of compromise. Legacy access controls and point-in-time security scanning are insufficient to defend these environments against sophisticated intrusions. Hardening the development lifecycle requires implementing continuous, automated verification at every stage, unifying security postures across developer endpoints, code repositories, package registries, build runners, and deployment guardrails into a cohesive defensive framework.

Ultimately, the objective of pipeline security is to build a resilient architecture capable of isolating and containing an intrusion. By automating cryptographic validation and policy enforcement from the initial code commit to the final production deployment, organizations can significantly reduce their overall attack surface, safeguard downstream consumers, and ensure that any individual compromise is rapidly isolated and resolved before it can spread.

Acknowledgements

This guidance would not have been possible without the assistance of Bhavesh Dhake, Brentyn Muir, Brian Meyer, Emilio Oropeza, Eyad Mahmoud, Franklin Ramos, Gursev Singh, Omar ElAhdan, Sara Takhim, Stuart Carrera, Stuart Munro, Will Silverstone, and the Mandiant Security Transformation Services team.

from Threat Intelligence https://ift.tt/d2TnmlQ
via IFTTT

Secrets Sprawl Is an Identity Problem That AI Just Made Impossible to Ignore

AI coding agents are changing how quickly developers can build and ship software as well as how quickly credentials can become exposed. According to GitGuardian’s 2026 State of Secrets Sprawl Report, commits identified as AI-assisted are leaking secrets at approximately twice the rate of human-written ones. Most of the fastest-growing categories of leaked credentials are now connected to AI services, meaning the tools meant to advance development are also accelerating the exposure of the keys development relies on.

This isn’t a new vulnerability; what is new is AI changing the scale and pace at which those mistakes can happen. A coding agent can read an entire project, modify files, generate configurations and interact with external services in the time a developer might take to review a single pull request. The main issue isn’t that AI agents sometimes encounter secrets but that many of those secrets were never designed for an environment in which software can act autonomously. AI coding agents are contributing to secrets sprawl by hardcoding credentials into more files and spreading existing ones into more systems than security teams can track and rotate.

How secrets sprawl has changed in the agentic AI era

Secrets sprawl occurs when credentials such as API keys, tokens and service account credentials accumulate across more systems than an organization can reliably inventory and rotate — hardcoded in source files, pasted into configurations and copied into tickets. Security teams have historically tried to control this sprawl by detecting exposed secrets retroactively; scanners watch repositories, pre-commit hooks catch what they can and security teams rotate credentials after an exposure is discovered. Those controls still matter, but AI agents expose the limitations of depending on detection alone. Agents can read local files, execute commands, call APIs, interact with Model Context Protocol (MCP) servers and modify configuration. Each additional capability creates another place where a credential may be required and another path through which that credential can spread.

This is why organizations should treat secrets sprawl in the agentic AI era as a Non-Human Identity (NHI) problem, not a model-behavior one. Every useful action an agent takes on another system has an identity behind it. When agents query a database, call an API and deploy to staging, some credential authorizes that action. Organizations cannot reliably predict every action an autonomous system will take, but they can control what the identity behind that system is allowed to access.

How AI coding agents can expose secrets

What makes coding agents useful is also what creates new credential risks: agents need context. An agent that can’t read an entire project doesn’t provide much assistance, especially one that must be re-authorized for every operation. Below are several ways this plays out in practice, demonstrating why organizations should be more careful when granting AI coding agents access to credentials and secrets.

Agents can access sensitive files in the project context

Developers often keep credentials in .env files and local configurations, left behind from a prior debugging session and never intended for source control. An AI coding agent with broad access to a project may be able to read those files along with the application code it was asked to analyze. To an AI agent, a configuration file containing a production API key is still part of the working environment, so unless access is explicitly limited, the credential may become available to the agent even if it is irrelevant to the task. This shifts security assumptions around developer workstations: Local plaintext credentials are no longer accessible only to the developer and the applications that explicitly reference them but are now also potentially available to software agents operating across the same environment.

Agent and MCP configurations can contain hardcoded credentials

Setup instructions for agents and MCP servers routinely simplify how developers connect AI applications with databases, APIs and other external systems. Because many integrations require authentication, that simplification often means pasting the credential directly into a configuration file. Since that file never enters version control, it's easy to assume the credential is safe. However, the credential may still exist in plaintext on a developer machine, often in a location the agent has permissions to read.

Secrets are duplicated across surfaces that teams may not scan

A secret rarely lives in one location; the same key ends up in an .env file, a CI/CD variable or even a Jira ticket while engineers troubleshoot a failed deployment. An AI coding agent connected to those systems introduces another vulnerability: since every copy of a secret authenticates, rotating the one in the repository leaves the rest working. This is why repository scanning alone cannot solve secrets sprawl. A large share of secret incidents can originate completely outside code repositories, with exposures in collaboration and ticketing tools, which is why rotating the copy found in a repository has minimal benefit if the same credential is valid elsewhere.

Agent credentials are often over-permissioned

An agent needs enough access to perform its work, creating pressure to grant broad permissions to ensure its tasks are useful. Permissions granted during prototyping to avoid errors may become part of a production process, so the original permissions with temporary intentions remain — no one revisits them once the workflow is running. The risk grows further in multi-agent systems. An orchestration layer holding keys for several agents may trigger a domino effect of compromised identities, with attackers inheriting access to everything the orchestrator was authorized to reach.

The governance gap is already measurable. In Keeper Security’s RSAC 2026 survey, 46% of respondents said AI-powered tools have access to critical systems and sensitive data, yet 76% of respondents said those identities aren’t consistently governed under privileged access policies. Even when access is granted, the controls that normally accompany that level of access often don't exist.

How to secure secrets in AI-assisted development

Banning AI coding tools entirely isn’t realistic for most organizations, and it honestly isn’t necessary. Instead, organizations should view AI agents as another identity operating across development environments and grant access accordingly. Here are several ways to secure secrets in AI-assisted development:

• Remove static credentials from the developer environment: Instead of storing secrets in .env files, MCP configurations or IDE settings, organizations should retrieve secrets from a centralized secrets management platform when they are needed. If the plaintext credential is not on the workstation, an agent cannot accidentally read it from the developer environment.
• Replace long-lived keys with short-lived, automatically rotated credentials: A static key that leaks remains a liability for as long as it stays valid, which may be months or years. A short-lived credential that expires in minutes and rotates on a set schedule narrows that window substantially and removes the need to find every copy before an attacker does.
• Give every agent its own scoped identity: Shared service accounts make it nearly impossible to identify which agent performed which action, and they ensure that every agent inherits the broadest permission any of them needs. Organizations should give each AI agent only the permissions required for its task, and make those permissions temporary whenever possible. By treating an AI agent like a contractor, organizations let it handle specific resources and take specific actions within a defined period of time.
• Extend secrets management beyond code repositories: CI/CD infrastructure, developer workstations, MCP configurations, ticketing systems and collaboration tools hold credentials that repository scanning never sees, and a large portion of secret incidents now originate in those attack surfaces. Security teams need to have more visibility beyond source control.
• Require a human in the loop for sensitive operations: Credential access, production deployments and privilege changes should not become autonomous and instead must involve explicit approval. Auto-approve modes should be an intentional policy decision with a defined scope, not a default that a developer enables once and never revisits.
• Inventory agents and MCP servers already running: Most organizations have more agents running than they think, installed by individual developers without proper review. Organizations should know which agents and MCP servers are operating in their environments, who owns them, which identities they use and what those identities can access.
• Log and audit all agent activity: NHIs need the same access trail as human identities. Without a record of which credential an agent used and what it reached, incident response can't help reconstruct a breach and has nothing to prove in compliance audits.

Secrets sprawl is an identity issue, not an AI one

Software development is one of the main enterprise use cases for AI, and no security team will change that by policy alone. AI agents didn’t create secrets sprawl; they exposed how many organizations have poor strategies for machine credential security. Realistically, the goal is ensuring that the secrets AI agents encounter aren’t worth stealing. That means eliminating unnecessary static credentials, removing standing privileges, shortening credential lifespans, separating identities and maintaining visibility into how machine identities are being used. More scanning doesn’t fix this problem because it still finds credentials once they’ve spread; what helps is centralized, zero-knowledge control over how secrets are stored, scoped and expired. Keeper Secrets Manager allows organizations to centrally secure infrastructure secrets, remove hardcoded credentials from development workflows and control secrets usage as part of a zero-trust, zero-knowledge platform. AI agents will continue working faster and more efficiently, but the credentials behind them must become shorter-lived and more narrowly scoped to help govern their access.

Note: This article was thoughtfully written and contributed for our audience by Ashley D’Andrea, Senior SEO and Content Marketing Specialist at Keeper Security.

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/iuIXapC
via IFTTT

17,000 URLs Reveal How ClickFix Turns Trusted Websites Into Malware Traps: Report by CTM360

ClickFix has become the most common way attackers get into enterprise networks, and it does it without an exploit, an attachment, or a file on disk. Our new global threat report traces the technique from a novelty in late 2023 to a subscription product with on-chain infrastructure and a state-sponsored user base, and explains why blocking malicious domains is no longer a useful defense.

Read the full report here: https://www.ctm360.com/reports/clickfix-beyond

A particular kind of security problem no patch will close. ClickFix is one of them.

The attack begins with a page that presents a problem the user believes is theirs to solve. A human verification check that will not complete. A browser that cannot render the page. A document that will not open. A Mac that is running low on storage. The page offers a remedy in the form of instructions, quietly writes the "fix" to the clipboard, and asks the user to open a system interface they already trust, paste, and press Enter.

That is the whole technique. There is no vulnerability for a scanner to find, usually no attachment for an email gateway to detonate, and no download for a browser's reputation check to score. The command is pasted by an authenticated interactive user into a native, signed, universally present binary, which is precisely the profile of legitimate administrative work.

It is now the leading initial-access technique in enterprise intrusion telemetry. Microsoft attributed 47% of the initial-access cases handled by its Defender Experts team in 2025 to ClickFix, ahead of conventional phishing. ESET measured a 517% rise into the first half of 2025, and a further 108% between the second half of 2025 and the first half of 2026. MITRE gave the behavior its own sub-technique, T1204.004, User Execution: Malicious Copy and Paste in March 2025, listing Windows, macOS and Linux as affected platforms.

Our report consolidates two independent bodies of primary analysis with open-source research: a campaign-level analysis covering more than 17,000 infected URLs serving fake Cloudflare verification pages, around 3,000 of them still actively serving the lure at the time of writing and a host-level analysis of a single compromised WordPress site examined entirely from the responses it returns to an ordinary visitor. Read together, they cover the full path from the injected page to an information stealer running inside a signed Microsoft process.

Three findings matter most for defenders.

The infrastructure is built to survive takedown

The injected script on a compromised website contains no attacker domain at all.

Instead, when a visitor loads the page, their own browser makes a free, read-only call to a smart contract on the Polygon blockchain. The contract returns an encoded string that decodes to the current lure hostname. No wallet, no transaction, and no cost. The technique is known as EtherHiding.

During a single day of analysis, that contract returned three different lure hosts in sequence and not one of the compromised websites was modified. The operator edits one on-chain value and every infected site follows within seconds. No registrar to complain to, no hosting provider to notify, and the RPC providers used to read the value are legitimate shared services that real applications depend on.

The same architectural idea appears again further down the chain, where Telegram channel descriptions and a Steam profile page resolve the malware's command-and-control address. Two independent resolution mechanisms at two different stages is a design decision, not an accident: the kit is built so that no single takedown breaks it.

The practical consequence is uncomfortable but clear. Blocking lure domains is close to worthless as a control. They rotate faster than any blocklist can be published.

Targeting is server-side, per-visitor, and deliberately hostile to analysis

The lure page reports the visitor's operating system and version back to the operator, which replies with a configuration naming which platforms to attack and which landing page to serve for each.

In the sample we analyzed, Windows was switched on. macOS and Linux landing pages were built and held in reserve. Mobile was suppressed entirely, and a cookie suppressed the overlay for repeat visitors for 90 days.

That configuration is worth dwelling on, because it undercuts a common assumption. The widespread belief that ClickFix is a Windows problem is a description of current configuration, not of capability, and it can be changed with a single server-side flag. The macOS branch was fully populated and functional; macOS lures are a mature parallel product line with their own pretexts, including a disk-space "maintenance" pretext styled as an Apple support article. The Linux slot existed and was empty.

Running underneath all of this is a traffic distribution system that polls the operator roughly every 1.5 seconds and can silently mark a session "verified" without ever showing the malicious instruction. Researchers, sandboxes and crawlers get a clean page. Intended targets get the lure.

The payload is gated on machine identity

The third finding is the one that should change how teams interpret their tooling.

In the dropper recovered from the live host, a hardware and account fingerprint machine GUID, volume serial, computer name, BIOS manufacturer, system model, GPU and username is base64-encoded directly into the download path. The command-and-control server therefore sees the victim's identity before it serves anything, and can return a payload chosen per machine, or nothing at all.

A sandbox is not merely detected and evaded here. It is served machine-specific content that is not the payload a real victim receives. Detonation-based verdicts on this chain are structurally unreliable, and the absence of a payload in a sandbox is not evidence that a site is clean.

Controls that depend on recognising attacker infrastructure will decay within hours. Controls that constrain what an interactive user is permitted to execute hold their value across every variant we have seen, and the ones that have not been named yet.

Read the full report here: https://www.ctm360.com/reports/clickfix-beyond

What the two samples say together

The two analyses were conducted independently, on different hosts, using different methods. One stops at the dropper because the payload was fingerprint-gated. The other follows the chain to the end: through three Telegram dead-drop resolvers and two layers of AES decryption, to Vidar Stealer executing inside a legitimately signed Microsoft binary by DLL side-loading.

They recovered the same traffic-distribution API shape, which points to a shared kit rather than convergent design. An open-source research closes the loop: Sekoia's June 2026 analysis of the ErrTraffic framework identifies the exact Polygon contract we observed as belonging to an operator cluster that distributes Vidar exclusively. The payload one sample could not retrieve is the payload the cluster operating that contract is documented to deliver.

We hold that correlation at moderate confidence; the framework is sold to multiple affiliates at around $380 a month, and cluster boundaries shift.

Why WordPress keeps appearing

WordPress is not incidental to any of this. It is the substrate the delivery business is built on: real domains, valid certificates, genuine inbound traffic, and in most cases, nobody monitoring. Reputation cannot be bought that cheaply anywhere else.

The report includes a finding that matters for anyone cleaning up an infected site. On the host we examined, the loader was not injected into a page, a post, or a theme file. It was appended by PHP to every dynamic response the server produced byte-identical across HTML, RSS and JSON alike which points to a must-use plugin that loads on every request and never appears in the plugin list. Alongside it sat roughly two dozen backdoor administrator accounts, created by script.

Deleting the visible script, removing the spam pages and deleting the one obviously rogue account is the most common response, and it fixes none of it.

What actually works

The report organises remediation around four chokepoints that every campaign passes through on every platform: a page must be able to write to the clipboard; a user must be able to open an interpreter; that interpreter must reach the internet; and something must persist, collect and exfiltrate.

Two controls are badly underused relative to their value. Blocking clipboard-write by default in managed browsers closes the entire class at the staging step, the page can still display instructions, but a user asked to retype an obfuscated one-liner by hand will usually stop. Forcing script interpreters and fetch utilities through an authenticated proxy breaks every staged chain in the report at the first hop, on Windows, macOS and Linux alike, without depending on a single indicator.

For users, one rule carries most of the value, and it does not decay when the artwork changes:

No legitimate website, verification check, error message, video call or software update will ever ask you to copy something and paste it into the Run box, PowerShell, Terminal, a command prompt or the File Explorer address bar.

If a page asks you to do that, the page is the attack.

The full report covers the technique's evolution from 2023 to 2026, the variant family including FileFix and CrashFix, a taxonomy of observed lure templates across Windows and macOS, the WordPress delivery layer, both sample analyses in full, a Mitre ATT&CK mapping, indicators grouped by expected lifetime, and platform-by-platform remediation for Windows, macOS, and Linux.

Read the full CTM360 report here: https://www.ctm360.com/reports/clickfix-beyond

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/demklca
via IFTTT

OpenAI Agent Bypassed Australian Medicare Portal Controls to Access Non-Public Files

An AI agent on an internal OpenAI research task bypassed access controls on an Australian government Medicare statistics portal in June, Prime Minister Anthony Albanese said.

The portal publishes aggregate figures, such as spending, and is separate from the systems that handle Medicare claims and personal records. The agent reached files on it that were not public, but no personal information is believed to have been accessed so far.

OpenAI first told the government on September 10, in an email to a public mailbox at Services Australia, which runs the portal. OpenAI says it found the activity in August. Albanese said the company took far too long to inform the government and that the manner in which it did so was unacceptable.

On June 18, the portal repeatedly refused the agent's data requests, but the agent found a workaround and gained unauthorized access. The government has not said how the agent got past them.

Services Australia has told the government that the agent also wrote files to an internal server. That is still being investigated. The evidence so far shows no wider compromise of the agency's network.

The non-public data was not particularly sensitive and has since been published. By September 24, the portal had been taken offline, and its data moved to data.gov.au and other secure platforms.

Acting Prime Minister Richard Marles told the ABC that national security information is subject to much stronger protections, while the portal's information was "kept behind a fence that the AI agent effectively climbed over."

OpenAI said in a statement to Fox Business that its models "took actions we did not intend" while looking up statistics about Australia during an internal evaluation.

The company found it during a wider review of what it calls misaligned model activity in training and evaluation, and checked what had been accessed before notifying Services Australia.

The activity involved several Australian government websites and services. The information its models accessed included aggregate health statistics and internal file names, and OpenAI found no evidence that patient records were accessed.

The government has described unauthorized access only at the Medicare statistics portal.

Services Australia saw OpenAI's email on September 11, checked that it was genuine and reported the incident on September 15 to the Australian Cyber Security Centre, part of the Australian Signals Directorate (ASD). The government made the incident public on September 24, Australian time.

Albanese raised his concerns, including the delay, with OpenAI chief executive Sam Altman in a phone call. By Albanese's account, Altman accepted that the company had not done well enough.

Marles called it a very serious incident with a relatively minor impact, and described OpenAI as cooperative.

ASD is helping with a forensic investigation, and Services Australia is running its own.

Albanese also announced a taskforce, led by the Department of the Prime Minister and Cabinet, to review whether existing processes are good enough to respond to AI-related cyber incidents. It will include the National Cybersecurity Coordinator, the Office of AI, ASD, the Australian AI Safety Institute and Services Australia.

The review will examine possible law-enforcement responses and changes to the law. The government will also seek urgent advice on whether any offenses were committed and whether to refer the case to the Australian Federal Police.

The incident will also go to Parliament's Joint Select Committee on Artificial Intelligence, and what the government learns from it will feed into its planned AI standards legislation.

Other Disclosures of AI Models Reaching Real Systems

AI agents tried to hack three public data websites in May and June, AI research lab Transluce said in a report published the same day as Albanese's announcement. One was an Australian government public health website run by the Australian Institute of Health and Welfare (AIHW).

On June 20 and 21, bot protection blocked agents working on a pharmaceutical data task from accessing the main AIHW site. The agents then probed for a vulnerability and retrieved a public file from a pre-production server.

The agents were doing ordinary data-retrieval tasks, not security work. They used urlquery.net, a public web page scanning service, to circumvent their access restrictions. The lab links at least some of the activity to agent swarms previously attributed to OpenAI.

OpenAI reported in July that its models, during internal cybersecurity evaluations, got around controls meant to keep them off the internet and broke into parts of Hugging Face's systems.

In September, OpenAI published reports on other cases found during training. In one case, a model used an exposed GitHub API key without authorization. In others, models uploaded files to public hosting sites without being asked.

Anthropic has disclosed four incidents in which its Claude models gained unauthorized access to real third-party systems during cybersecurity evaluations built by an outside partner. The models had been told they had no internet access, but a misconfiguration left it open.

Meta said in August that a pre-release version of its Muse Spark 1.1 model exploited a flaw in a real website and changed its database during an exercise run by the same partner, Irregular. Irregular had left internet access open and, by mistake, given the model the real site's name as its target.

Irregular says later public disclosures about its evaluation environment refer to the same underlying issue, first disclosed on July 30, and "are not materially separate incidents."

Separately, the UK's AI Security Institute reported in August that AI agents in its cyber tests took 19 unapproved actions on the live internet across 10 of 122 runs, including an attempted supply-chain attack on an open-source project.

The most serious attempts failed, and the institute found no evidence of real-world harm. Internet access had been intentionally enabled for the tests.

ASD published a notice on August 11 about a different case, in which an AI assistant made unapproved changes to a gym booking system. It said organizations running online services should consider that "AI agents might identify and exploit vulnerabilities at speed and scale."

Its advice for those building websites and online services includes security and quality checks, vulnerability scanning, and proper user authentication.

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

Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure

Threat actors have begun to actively exploit a critical security flaw in WordPress within hours of public disclosure.

The vulnerability in question is CVE-2026-87902 (CVSS score: 9.2), which could allow an unauthenticated attacker to obtain remote code execution (RCE).

"An unauthenticated attacker can make get_page_template() page-template resolution include a chosen readable local .php file outside the active theme directories," WordPress said in an advisory released two days ago. "If relevant preconditions for both the server environment and the active theme are met, this can lead to RCE."

Successful exploitation hinges on meeting the two pre-requisites -

• The active child or parent theme contains a top-level directory whose name starts with page- (e.g., page-templates).
• A chosen local .php target file exists on the server and is readable by the web server account. (e.g., pearcmd.php).

In a statement shared with The Hacker News, Previdian said it's seeing exploitation attempts targeting CVE-2026-87902 against its honeypot network, with the malicious requests originating from an IP address (104.194.9[.]227) located in the U.S. state of New Jersey.

These requests include the local PHP file /usr/local/lib/php/pearcmd.php, writing a file to /tmp/, and then including a PHP upload script hosted on GitHub ("raw.githubusercontent[.]com/MrG3P5/web-shell/refs/heads/main/uploader.php").

"Although this is undoubtedly a serious vulnerability, certain preconditions make exploitation less likely," Previdian's founder and CEO Ryan Dewhurst said. "Because WordPress has auto-updates enabled by default, we're likely to see mass-exploitation attempts, but relatively few actual compromises."

Telemetry data from Previdian has recorded a total of 68 exploitation attempts starting September 23, 2026. Some of the efforts have also originated from an Indonesia-based IP address.

WordPress security company Patchstack has also warned that the malicious requests have expanded from reconnaissance against harmless core files to active exploitation in which attackers include "pearcmd.php" and use it to write PHP files to disk, corroborating findings from Previdian.

The first exploitation effort was recorded on September 22, 2026, at 11:49 a.m. UTC, the same day patches were shipped for the flaw. In addition, the activity involves arbitrary file writes with attacker-controlled PHP content in locations like "/tmp" and "/var/tmp." Observed file names include -

• wp-pear-rce-flag.php
• poc87902.php
• luci_<random>.php
• zeta_<random>.php

Some of the IP addresses linked to the malicious attacks -

• 43.250.53[.]42
• 180.251.159[.]243
• 195.178.110[.]247
• 107.189.14[.]87
• 45.61.184[.]170
• 92.246.130[.]76

In light of active exploitation, website administrators are advised to apply WordPress version 7.1.2 (or 7.0.6, 6.9.9, 6.8.10) as soon as possible and audit for signs of malicious activity.

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

Thinware SimpleVM: A Practical Free-Forever KVM Hypervisor for VMware Administrators Seeking a Smarter Path Forward

The virtualization market has shifted dramatically in recent years and continue to do so. Many enterprises or small businesses face challenging decisions: absorb significant cost increases for VMware, accept unwanted product bundles, or begin the journey toward alternative solutions. Many SMBs has already moved on, now the mid-size and enterprises. For those looking to reclaim control over their infrastructure budgets and operational freedom, Thinware SimpleVM emerges as a compelling option. This lean, KVM-based Type-1 hypervisor combines enterprise-grade capabilities with genuine simplicity and a free-forever licensing model.

Having followed various KVM-based platforms over time, SimpleVM stands out for its focused design philosophy. It avoids unnecessary complexity while delivering the features most teams need for reliable production environments.

Understanding SimpleVM’s Foundation and Design Goals

SimpleVM is built directly on KVM with a hardened operating system base that maintains strong compatibility with RHEL ecosystems. This choice provides excellent driver support, security features (including SELinux), and long-term stability. The platform is engineered as a purpose-built hypervisor rather than a general-purpose Linux distribution with virtualization layered on top.

The development team emphasizes zero vendor lock-in. Everything runs on open, trusted components, meaning you retain full sovereignty over your environment. There is no telemetry collection, no forced cloud connectivity, and no artificial restrictions on scaling. You can deploy on standalone hosts or grow into clusters without licensing penalties.

Key Features in Detail

Deployment and Initial Setup – One of the biggest advantages is speed. The guided installer takes you from bare metal to a functional host in minutes. Hardware support is broad thanks to the Linux kernel foundation, accommodating everything from older server hardware still running in many datacenters to brand-new deployments. This flexibility removes one of the common barriers when planning migrations.

If you’re familiar with Rocky Linux, you’ll find exactly that as SimpleVM uses Rocky Linux as its foundations. The deployment of a single host takes few minutes and it is comparable to other platforms including VMware ESXi.

 

Login screen of Thinware SimpleVM

 

Web-Based Management Console – The integrated dashboard serves as your central control point.

Administrators can:

• Monitor host resources and VM performance in real time
• Create, clone, snapshot, start, stop, and migrate virtual machines
• Manage storage pools and individual volumes with thin provisioning support
• Configure virtual networks, bridges, VLANs, and firewall rules
• Access a web-based terminal and file browser for host maintenance

 

The UI is simple but effective

 

The interface is clean and responsive, making daily tasks efficient without requiring deep command-line expertise for routine operations.

Clustering, Live Migration, and High Availability – For production environments, SimpleVM supports host clustering (starting from simple 2-node setups up to larger configurations). Live VM migration allows you to move running workloads between hosts with minimal or no interruption — the equivalent of vMotion. When combined with shared storage (NFS, iSCSI, or Fibre Channel), you gain automated failover capabilities for higher resilience.

Resource pooling across clustered hosts improves overall utilization. While it may not include fully automated load balancing like some high-end DRS implementations, manual and policy-driven migration tools cover the majority of maintenance and optimization scenarios effectively.

Light UI is also available.

 

Light UI showing the default overview

 

Security and Compliance Features – Hardened SELinux policies, granular firewall controls, and secure boot options provide strong defaults. Role-based access in the web console helps enforce proper administrative boundaries. For organizations with compliance requirements, the ability to run everything on-premises with no external data sharing is a significant advantage.

Support, Patching, and Long-Term Maintainability

A common concern with alternative platforms is “What happens when we need help or updates?” SimpleVM addresses this thoughtfully.

Patching and Updates: The platform follows a 10-year Long Term Support (LTS) philosophy. Security patches and maintenance updates are delivered regularly and can be applied directly through the web console with minimal disruption. This approach provides stability similar to enterprise Linux distributions while keeping the hypervisor layer focused and lightweight.

 

Patching is via the web UI – simple

 

Professional Support Options: Thinware offers dedicated support services for organizations that require it. You can reach out via sales@thinware.net or support@thinware.net for assistance with deployment planning, performance tuning, troubleshooting, or priority handling of issues.

Support is available as an add-on rather than a mandatory subscription tied to the core product. This flexible model works well for teams that want self-sufficiency for standard operations but need expert backup for critical environments.

This combination – free core software with optional professional support gives organizations predictable budgeting while ensuring they are not left without recourse when needed.

Backup and Data Protection: The Veeam Question

No virtualization platform evaluation is complete without addressing backup and recovery. SimpleVM deliberately does not include a built-in backup engine, giving you the freedom to choose tools you already trust. I have interviewed Jeremy Brown, the CEO of Thinware, in my detailed post about SimpleVM. You can get the whole picture why SimpleVM exists. As concerning backups, here is what he said.

Quote:

For backup we want our customers to use whatever tool they prefer. Most of the well know/used packages out there already support KVM so there is no issue there. We chose not to include backup into SimpleVM for this reason.

We still have quite a few customers using Thinware vBackup so we will be retooling vBackup to support KVM as well.

Veeam Compatibility Clarified: Veeam Backup & Replication does not have direct, first-class support for SimpleVM at this time. Because SimpleVM is a relatively new KVM-based platform, it is not listed among Veeam’s officially supported hypervisors (such as VMware, Hyper-V, Proxmox VE, or oVirt/RHV).

That said, practical compatibility is often achievable because it uses standard KVM technology. Many organizations successfully protect generic KVM/libvirt environments using:

• Guest-level agents (Veeam Agent for Windows/Linux)
• Application-aware processing inside the VMs
• File-level or volume-level backups

Recommendations:

• Thoroughly test your intended backup method (agent-based is the most reliable path currently) in a proof-of-concept.
• Monitor future Veeam releases – support for additional KVM platforms has expanded over time.
• Consider complementary solutions such as Thinware’s own vBackup (being updated for KVM) or other open-source options.

The lack of direct integration is important to note for production planning. While not a deal-breaker for many teams (especially those comfortable with agent-based protection), it requires validation during evaluation.

Migration Strategies from VMware

Moving workloads requires careful planning, but SimpleVM provides helpful documentation for the process. Common approaches include:

• Exporting VMs from vSphere and importing them into SimpleVM.
• Using standard conversion utilities (V2V) compatible with KVM as a destination.
• Phased migrations starting with development, test, and less critical production systems.

Because the underlying technology is KVM, virtual hardware compatibility is generally good. Take time to test performance and driver behavior (especially paravirtualized drivers for disk and network) after migration. Storage and networking reconfiguration may be necessary but is usually straightforward.

Start small, document everything, and leverage Thinware support if you want guidance during the initial phases.

Who Should Evaluate SimpleVM?

SimpleVM is particularly well-suited for:

• Mid-sized enterprises and SMBs facing VMware licensing pressure
• Organizations prioritizing cost predictability and operational simplicity
• Teams already comfortable with Linux-based infrastructure
• Environments where 80-90% of workloads are standard server VMs rather than highly specialized use cases

It may not be the perfect fit if you rely heavily on advanced software-defined networking, container orchestration integration, or specific VMware-exclusive features. However, for the broad majority of server virtualization needs, it delivers excellent value.

While writing the article, I quickly spun a new VM in the lab.

 

Example of Windows Server 2022 VM running

 

Potential Considerations and Limitations

As with any platform, transparency is important. SimpleVM is relatively new in its current form, so the ecosystem of third-party tools and community knowledge is still growing compared to more established alternatives. Hardware certification is less rigid (a benefit for flexibility but requires your own validation). Some advanced automation features found in premium enterprise suites may require custom scripting or additional tools.

That said, the rapid deployment, clean management layer, and free licensing often outweigh these factors for many organizations.

Real-World Operational Benefits

Admins who adopt solutions like SimpleVM frequently report:

• Lower total cost of ownership
• Faster provisioning of new environments
• Reduced time spent on licensing compliance
• Greater flexibility in hardware refresh cycles

When combined with existing monitoring tools and your preferred backup solution (such as Veeam), you can build a modern, cost-effective stack tailored to your needs.

Getting Started Today

Visit simplevm.com and download the latest version.

1. Deploy on a test server or a small cluster.
2. Configure storage and networking, then create sample VMs.
3. Test live migration, backup, and patching workflows.
4. Document performance and plan your production rollout timeline.
5. Engage with Thinware early if you anticipate needing support during migration.

Final Words

Couple of years back when the domination of VMware was reaching heights, SimpleVM would probably be forgotten quickly, but now with VMware pricing skyrocketed, this solution only makes sense and it is another viable and simple VMware alternative which runs at a fraction of the costs.

The days of single-vendor dominance in virtualization are definitely over. Solutions like SimpleVM demonstrate that teams can achieve high reliability, good performance, and essential enterprise features without ongoing licensing burdens. The combination of a free core platform, straightforward patching, optional professional support, and compatibility with established tools like Veeam creates a practical migration path for many organizations.

If you are an administrator evaluating options to modernize or right-size your virtualization strategy, SimpleVM deserves a place on your shortlist. A few days in the lab can provide clarity on whether it aligns with your technical and financial goals.

The move away from high-cost ecosystems is not just about saving money – it’s about regaining control and building infrastructure that serves your business rather than the other way around.

What are your biggest drivers for exploring alternatives right now? Cost savings, support flexibility, or something else? Feel free to share your thoughts and experiences in the comments section below. The community benefits when we exchange real-world insights during these transitions.

FAQ

Is Thinware SimpleVM free?

Yes. Thinware SimpleVM uses a free-forever licensing model for its core hypervisor. Professional support is available separately for organizations that need help with deployment, troubleshooting, performance tuning, or other production requirements.

What hypervisor technology does SimpleVM use?

SimpleVM is built on KVM and uses Rocky Linux as its foundation. It is positioned as a purpose-built Type-1 hypervisor with support for SELinux, standard Linux hardware drivers, and RHEL-compatible infrastructure.

Does SimpleVM support clustering and live migration?

Yes. SimpleVM supports host clustering, including configurations starting with two nodes. Administrators can migrate running virtual machines between hosts, and shared storage such as NFS, iSCSI, or Fibre Channel can be used for high-availability configurations.

Does SimpleVM include built-in backup?

No. SimpleVM does not include its own built-in backup engine. Thinware’s approach is to let administrators choose their preferred backup solution rather than bundling one with the hypervisor.

Does Veeam support Thinware SimpleVM?

Veeam Backup & Replication does not currently provide direct, first-class support for SimpleVM. Organizations can still evaluate agent-based protection with Veeam Agent for Windows or Linux, application-aware processing inside VMs, and file- or volume-level backup methods.

Can VMware virtual machines be migrated to SimpleVM?

Yes. VMware workloads can be moved by exporting VMs from vSphere and importing them into SimpleVM or by using V2V conversion tools compatible with KVM. A phased migration starting with development, test, or less critical systems can help validate storage, networking, drivers, and performance before a wider rollout.

Who should consider Thinware SimpleVM?

SimpleVM may suit SMBs and mid-sized enterprises looking for a lower-cost VMware alternative, teams already comfortable with Linux-based infrastructure, and environments where most workloads are standard server virtual machines.

What are the main limitations of SimpleVM?

SimpleVM has a smaller third-party ecosystem and knowledge base than long-established virtualization platforms. Some advanced automation or VMware-specific functionality may require extra tools or custom scripting, and hardware should be validated for the intended environment.

from StarWind Blog https://ift.tt/EfHnUBP
via IFTTT