Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Cyber Security. Show all posts

Elementor Pro WordPress Flaw Exploited to Upload Webshells and Execute Commands

 

A critical vulnerability in the Elementor Pro WordPress plugin is being actively exploited to upload malicious PHP files and execute commands remotely on the affected websites. 

The vulnerability, tracked as CVE-2026-32475, affects the Elementor Pro versions 4.2.1 and lower. This issue was patched on August 19. Elementor Pro has more than 6 million active installations and is widely used to design WordPress websites with drag-and-drop tools. 

The vulnerability is related to the insufficient validation of file-upload arrays in Elementor Pro forms. Attackers can exploit this issue by uploading an empty file as the first element of the upload array and a malicious PHP file as the second. Then the plugin will not validate the following files in the array, thus allowing the attacker-controlled PHP payload to be successfully uploaded on the server without any additional checks. 

Once the malicious file is uploaded, it will be stored on the /wp-content/uploads/elementor/forms/ directory with a randomly generated name but preserving the attacker’s .php extension. Then the attacker will be able to directly access this file on the server to execute arbitrary commands and potentially deploy a webshell for further attacks. To successfully exploit the vulnerability, an attacker needs to have access to a WordPress website with a published Elementor Pro Form widget that contains at least one File Upload field. 

This is a relatively common case for WordPress websites that utilize Elementor Pro forms. WordPress security company Defiant, which operates the Wordfence firewall, noted that exploitation began on August 19, the same day Elementor released the 4.2.2 version to address the vulnerability. Wordfence observed that the traffic was especially heavy between August 19 and 23, having blocked more than 190,000 attempts to target its customers. 

Wordfence has identified IP addresses that were responsible for thousands of exploitation attempts. Website administrators can add these addresses to their blocklists to protect their WordPress sites. Administrators that utilize Elementor Pro need to make sure to update their software to the latest versions, preferably 4.2.2 or newer. Moreover, they should check their /wp-content/uploads/elementor/forms/ directories for any unexpected .php files. 

As the name suggests, the directory is supposed to contain the files that users upload with Elementor forms, meaning that the discovery of any .php files should be investigated and potentially result in an intrusion assessment.

redactproxy, a tool that lets pentesters use AI without leaking client data

AI coding agents are now part of a lot of security work. They are good at the parts a tester has no time for: going through every request, every parameter and every file rather than a sample of each. But none of that work happens on your machine. Everything the agent reads is sent to a model running on someone else's servers. So are you sending your client's data to an AI provider?

Where the client's data goes

The moment you point one of these agents at a live engagement, everything it touches reaches a third party. Client domains. Internal hostnames. Credentials pulled out of a config file. Employee email addresses. The client's own name, in the folder path, in the ticket reference, in the commit message. A testing agreement authorises you to access the client's systems. It rarely says anything about transmitting their contents to a model provider, and the same gap shows up against PCI-DSS, HIPAA and SOC 2 data-handling clauses.

The usual advice lands in one of two places: run a local model, or don't paste client data. Both work. Both cost you the thing you wanted. A 7B model on a laptop is not the model that spots the subtle chain across three hosts, and an agent you feed carefully redacted scraps by hand is an agent you are babysitting instead of using.

There is a third option. Almost none of that data needs to be there in the first place: the model does not need the real hostname to reason about a finding on it. It needs a hostname that stays the same every time it sees it.

That is where redactproxy(https://github.com/CSPF-Founder/redactproxy) comes in.

Where the model runs

Before we get to what redactproxy does, we need to understand where the work actually happens. Claude Code is the part on your machine: a terminal tool that reads your files, runs your commands and collects the output. The model is not on your machine at all: it runs on an AI provider's servers, Anthropic for example. Claude Code does no reasoning of its own, so anything it needs an answer about, including the scan output and the config file it just read, is sent to those servers over the API.

RedactProxy

redactproxy is an open-source tool from the Cyber Security & Privacy Foundation. It sits between Claude Code and the provider, on your own machine, and rewrites that API traffic in both directions. On the way out it replaces real client values with stable fake ones. On the way back it puts the real ones in again, before Claude Code ever sees the response.




The provider only ever sees placeholders. Your tool calls still run against real infrastructure, because the substitution back happens before the response reaches the agent. When the model writes a Bash command against a placeholder hostname, Claude Code receives the real hostname and runs it against the real host. Not just the first time: on every response, ten turns later, for the life of the conversation.

The swap happens inside the traffic itself, so nothing about the way your team works changes. No telemetry, no sync, no backup: everything it stores stays on the machine you run it on.

What the model receives

Here is some scan and config-dump output, exactly as Claude Code would send it, next to what the model actually receives.



What changed, and what didn't:
  • The mail. subdomain survives, and the same organisation placeholder appears in both the hostname and the email address. The relationship between them is intact.
  • The host octet .19 survives. Only the /24 network changed, so hosts that were adjacent stay adjacent.
  • The AWS key still looks like an AWS key, so the model knows what kind of secret it found without seeing the secret.
  • The connection string collapses into one opaque placeholder, because the whole credential span is sensitive.
  • The nginx banner, the latency, the port, the Dell OUI comment: untouched. None of them identify the client.

Stable placeholders

An engagement is redactproxy's word for one client project. Inside one, the same real value always gets the same fake. The hostname that became tok5198ede8bdbb1ada.internal this morning is still that same fake tomorrow, and in every request in between. This is not a convenience. It is the reason the tool is usable at all.

The model can still work out that two hosts belong to the same organisation. It just never learns which organisation.
Because tok1a2b3c4d5e6f7890.com and mail.tok1a2b3c4d5e6f7890.com are consistently the same fake, the model can reason that a finding on one host relates to a finding on another, that an email address belongs to the same company as a web server, that the same credential turned up in two places. All the analytical work survives. The identity does not.

The mappings live in the engagement's own folder and survive restarts, so the placeholder the model saw yesterday is still the same one today. Each engagement is self-contained and shares nothing with the others.

Placeholder shapes

Redaction that destroys structure destroys usefulness. Where a value's shape carries something useful but not identifying, the shape is kept:


The ranges are not arbitrary. Every fake comes from a space that cannot collide with something real: an IPv4 block reserved for equipment testing rather than one of the private ranges internal engagements actually target, the 555 phone exchange reserved for fiction, MAC addresses that can never belong to a real manufacturer. Fake credentials carry the string FAKE in a position where a real key can only hold a digit or a letter A to F, so no vendor could ever issue one.

What it detects

Detection is regex plus a validation step. No model in the loop, no network call, no learning. The detector set covers, roughly:
  • Network identity: domains and hostnames (bare or inside URLs), IPv4, IPv6, MAC addresses.
  • People: email addresses, NANP and international phone numbers.
  • Credentials for 25+ vendors: AWS, GitHub, GitLab, Slack, Stripe, Razorpay, Google, npm, DigitalOcean, Cloudflare, Azure, Docker Hub, CircleCI, Terraform, Snyk, Vault, Twilio, SendGrid, OpenAI, Anthropic and more, plus JWTs, bearer tokens, connection strings, PEM private keys and password hashes.
  • Regional PII: Indian Aadhaar and PAN numbers.
  • AD artifacts: machine account names, GPP cpassword values.
  • Client identity: whatever you add by hand, which is the part that matters most. See below.
There is also an allowlist, split into categories you can toggle. Your own out-of-band testing services (burpcollaborator.net, interact.sh, webhook.site) are never the client's, and common CDN and public dev platform hostnames say nothing about who the client is. Every category can be switched off per engagement.

Only the parts of a request that carry content get scanned, and only the values that match get replaced. Everything else is left exactly as it was. MCP tool calls and results are scanned too, because an MCP server is local infrastructure producing exactly the client data this exists to keep in.

Fail closed

If the proxy cannot finish redacting a request, it returns an error instead of sending it on. A malformed request, a detector that errors, a store that cannot save a new mapping: all of them fail the request rather than let it through.

An unredacted forward is the one outcome this project treats as worse than a broken request.

Setting up an engagement
go install github.com/CSPF-Founder/redactproxy/cmd/redactproxy@latest
Then, in a folder for the engagement. Name it after an engagement code, not the client; the Known gaps section explains why that matters more than it looks.
cd ~/engagements/eng-2026-014
redactproxy wizard --engagement eng-2026-014
The wizard asks four things. First, customer name variations: the legal name, the trading name, abbreviations, product names, internal codenames. No detector can match a name, so this is the only way they get redacted. They become case-insensitive substring matches, so XYZCorp also catches XYZCorporation.

Second, domains. Give the base domain only. Subdomains, email addresses at that domain and URLs all resolve from it automatically. Internal-only names work too: an AD forest, or any private scheme that will never appear on a public suffix list.

Third, which API this engagement talks to. Real Claude by default. redactproxy never asks for an Anthropic credential; it forwards Claude Code's own authentication untouched. Anything else speaking the Anthropic Messages API works too, z.ai for example, and each engagement remembers its own choice, so two client projects can run against different providers side by side.

Fourth, it offers two conveniences for the folder: a CLAUDE.md note explaining the placeholder shapes, and a .claude/settings.local.json that points Claude Code at the proxy and closes several channels that bypass the proxy entirely.

Then:
redactproxy      # terminal 1
claude           # terminal 2, already pointed at the proxy
That terminal running the proxy is also a live console. Type show to see every mapping minted so far, remove <value> to drop a bad one, or rules block "XyzExample" to add a value mid-session without interrupting anything.

Two files the wizard writes

The CLAUDE.md note is not decoration. Without it, a session sees strange placeholder values with no explanation: it corrects them as typos, hesitates to use them in tool calls, or retypes them from memory slightly wrong. The note tells the model these are stable identifiers to copy verbatim. It also covers a trap worth knowing yourself: if the model decodes base64 inline, the decoded content lands in its own output completely unprotected, because the encoded form passed through unredacted. Decoding to a file with Bash and reading the file back gives that content a normal pass through redaction.

The settings hardening closes paths that never touch ANTHROPIC_BASE_URL at all. The Artifact tool is a confirmed leak path: a report published through it goes straight to a hosted claude.ai URL, entirely unredacted, through a separate service call the proxy never sees. The wizard removes it from the session entirely rather than prompting for it each time, because a permission prompt can be approved out of habit and a tool that was never offered cannot leak anything. It also turns off WebFetch's safety check, which sends the target hostname to Anthropic before the fetch, whichever provider the engagement uses. A domain being reconned is exactly the value this tool exists to keep off side channels.

Known gaps

redactproxy ships a Known gaps page, and it is worth reading before you point this at real client data. The ones that matter most:
  • Your folder name is the big one, and redaction cannot fix it. Claude Code puts its working directory into the system field of every request, and that field is deliberately never scanned. A folder called xyz-example-bank-pentest sends "xyz example bank" to the model on every single request no matter what your rules say. The tool warns about it, at wizard time and at startup, but the only fix is to name engagement folders after an engagement code.
  • Encoded data passes straight through. A .env piped through base64, an xxd dump, Terraform state: none of it looks like anything to a regex. Decode locally first.
  • Names and prose are not detected. This is what rules block is for, and why it is the wizard's first question. A company name shows up in URL paths, ticket references, code comments and commit messages, and no detector can recognise it.

Who this is for

Pentest and consulting teams who want the productivity of an AI coding agent on a live engagement, and who would rather not explain to a client why their internal hostnames are in a third party's logs.

It was built for pentest work, and that shapes the vocabulary: engagements, clients, findings. Nothing in the redaction is specific to offensive work, though. Blue teams and infrastructure teams hit the same problem: a SOC analyst pasting alerts full of internal hostnames, a sysadmin debugging a manifest with credentials in it, anyone under an NDA who wants an AI agent working on real data. The detectors only care about the shapes they recognise, not why you are looking at them.

1 Folder Was All It Took: Security Researchers Find AI Coding Agents Can Be Hijacked Before a Single Prompt Is Typed




Opening a folder should not be a security event. For users of at least seven popular AI coding agents, until recently, it could be one. A newly documented set of vulnerabilities, tracked under the name GitSpawn, shows that pointing an AI coding assistant at a project folder was enough to hand an attacker code execution on the developer's own machine. No prompt had to be typed. No permission dialog had to be clicked. In some cases, the user had not even logged in yet.

The affected tools include Anthropic's Claude Code, OpenAI's Codex, Cursor, Block's Goose, Nous Research's Hermes Agent, Alibaba's Qwen Code, and xAI's Grok Build. These products sit on an enormous number of developer machines. Claude Code's npm package sees more than 77 million downloads a month. The tools examined most closely in the disclosure carry a combined GitHub following approaching half a million stars. This flaw reached deep into the software supply chain.


What actually happens when you open a folder

An AI coding agent needs context the moment it launches inside a project: what branch is checked out, which files changed, what the codebase looks like. The fastest way to get that information is to ask git, the version control system nearly every software project runs on. So these agents run background commands like `git status` or `git diff` as soon as a folder opens, often before the assistant has said anything to the user.

That part is normal. The danger sits in a git feature called `core.fsmonitor`, a performance setting built to let large repositories speed up status checks by handing file-change detection to an external helper program instead of scanning every file each time. Git learns which helper to run by reading the repository's own configuration file, `.git/config`. That file ships with the project. It does not live on the user's machine.

Anyone who builds a repository controls that file, which means anyone who builds a repository can set `core.fsmonitor` to run whatever command they want. Nearly every git command that touches a project's working files triggers something called an index refresh, and that refresh is what reads the setting and runs it. So the moment an AI coding agent runs an ordinary git command inside a booby-trapped folder, git executes the attacker's command on the developer's machine, under the developer's own account. Because the agent's own code is making that subprocess call rather than something routed through its interface, none of the approval prompts or sandboxing built into these tools ever sees it happen.

There is a limit worth knowing. A standard `git clone`, `fetch`, or `pull` will not trigger this, because those operations do not carry the repository's local configuration along with them. The malicious repository has to reach a victim as a set of files with its `.git` directory already inside: a zipped folder sent over email, a shared drive, a synced folder, a USB stick passed at a meeting. Developers, contractors, and consultants hand off projects this way constantly, which is what makes the delivery method plausible.


Which vendors fixed it, and which did not

Eight distinct findings were reported privately across the seven agents before this went public. Four of them were still unpatched at the time of publication.

Goose, maintained by Block, shipped a fix in version 1.44.0. The issue was catalogued as CVE-2026-72718, with a severity score of 7.0. Cursor and OpenAI's Codex both carried variants of the same flaw and have since patched them, though in both cases the vulnerability had already reached the vendors through other researchers' independent reports. Anthropic fixed the core.fsmonitor path in Claude Code with version 2.1.196. A second issue in the same product, tied to the `claude ultrareview` command and a different git configuration key, was still working as of version 2.1.252 at publication time. That configuration key has not been made public while the issue stays open, so as not to hand out a working template.

Two vendors had shipped nothing. Alibaba's security response center accepted the report on Qwen Code but had not resolved it by publication. xAI's Grok Build remained vulnerable through version 1.0.13; an earlier, related report had been closed by the company as merely informative before this disclosure connected it to the same bug. Hermes Agent's maintainers never triaged the report despite six separate contact attempts across five channels. The flaw was eventually assigned CVE-2026-71963 by VulnCheck, an independent numbering authority that can step in when a vendor stays silent.


This bug has been seen before

The shape of GitSpawn is not new to anyone who has followed git security for a while. Independent researcher Justin Steven documented abuse of the fsmonitor hook back in 2022. Visual Studio Code built its workspace trust model in 2021 to stop untrusted folders from running code the second they were opened in an editor. AI coding agents brought a version of that same exposure back by running git commands in the background before any of those trust protections had a chance to apply.

That is the part worth sitting with. Nothing about how these models reason or respond caused this. The exploit runs entirely in ordinary software plumbing, the subprocess call an agent makes to figure out where it is, firing before any of the safeguards a user assumes are in place actually engage.


What to do about it

If you receive a project as raw files rather than through a direct git clone, whether by email, shared drive, or a USB stick, check `.git/config` before opening it in an AI coding agent or any development tool. Anything in that file that names an external program to run deserves a second look.

If you build one of these tools, the fix is narrow: disable risky configuration keys like `core.fsmonitor` on every background git call, for example by running commands with the flag `-c core.fsmonitor=false` instead of trusting whatever the repository hands you.

AI coding agents keep taking on components they did not write and did not choose: plugins, extensions, connections to outside services, most of which arrive as files carrying their own settings and get trusted the moment they load. GitSpawn shows what happens when that trust runs ahead of the checks meant to govern it. The next version of this bug probably will not look like a git command at all.

5 Million WordPress Sites Exposed to SQL Injection Vulnerability


A severe security flaw in a famous WordPress migration plugin and backup could allow threat actors to take command of over millions of sites, experts have warned.

About the security flaw

The security flaw is tracked as CVE-2026-19949, it impacts the Backup plugin and All-in-One WP Migration, which is utilized by over five million active wordpress installations. The plugin lets site owners to migrate, import, export, and backup sites, this consists of media files, themes, plugins, and databases.

As per Bleeping Computer, the flaw is a second-order SQL injection vulnerability that could permit an unauthorized threat actor to run malicious code on a compromised site. The flaw impacts variants 7.109 and earlier and has been given high severity, with a 8.8 CVSS score.

Reporting of the flaw

The vulnerability was found by security expert Jack Taylor, who reported the incident to cybersecurity company Wordfence, which investigated and disclosed the flaw. On August 15, 2026, Wordfence informed the plugin’s developer, Servmask, which released variant 7.220 on August 20 to patch the flaw. 

“On August 14th, 2026, we received a submission for an Unauthenticated Second-Order SQL Injection vulnerability in All-in-One WP Migration and Backup, a WordPress plugin with more than 5 million active installations,” Wordfence reported.

Attack tactic

Contrary to flaws that can be abused immediately, this vulnerability consists of an extra step. Threat actors first place specially tailored data on a compromised website. 

The malicious information remains latent until a website admin does a backup restoration of the archive. “This vulnerability makes it possible for unauthenticated attackers to inject SQL that is later executed when a site administrator performs an archive restore, which can be used to leak the plugin’s secret key and ultimately achieve remote code execution, leading to complete site takeover,” Wordfence said.

Misuse of malicious data

In the restoration stage, the stored malicious data can be used as SQL commands which allows threat actors to take out sensitive data from the website’s database.

An important target is the plugin’s secret ai1wm_secret_key.. If a threat actor accesses this key, it can possibly be used to move from database access to remote code execution (RCE), allowing the threat actor more control over the compromised website.

Through RCE, threat actors could install malicious code, change website files, and create backdoors.

Addressing the flaw

ServMask addressed the CVE-2026-19949 in variant 7.110 of the plugin. Users are advised to update their websites to the latest patched versions of Backup and All-in-One WP Migration.

On August 20, ServMask addressed the CVE-2026-19949 vulnerability in version 7.110 of the plugin.

Four Cybersecurity Habits That Can Do More Harm Than Good When Misused



Cybersecurity advice is often reduced to simple rules: change passwords regularly, avoid public Wi-Fi, install antivirus software and enable two-factor authentication. These recommendations were created for good reasons, but the threat landscape and the technology protecting users has changed.

The problem is not that these safeguards have become useless. Instead, rigidly following outdated versions of the advice can create false confidence, encourage risky behaviour or distract users from more effective protections.

Here are four familiar cybersecurity habits that need to be reconsidered.

1. Changing Every Password on a Fixed Schedule

For years, organizations required employees to change their passwords every 30, 60 or 90 days. The intention was to limit the amount of time a stolen password could remain useful.

In practice, frequent forced changes can encourage people to select predictable passwords or make minor alterations, such as replacing “Password1” with “Password2.” This provides much less protection than organizations may assume.

The current NIST Digital Identity Guidelines advise service providers not to demand periodic password changes unless there is evidence that a password has been compromised. NIST instead emphasizes longer passwords, blocking commonly used or compromised credentials and permitting the use of password managers.

A better approach is to give every account a long, unique password generated and stored by a reputable password manager. A password should be changed immediately if it appears in a breach, is entered on a suspicious website or may have been exposed through malware.

Where available, users should also consider passkeys, which remove the need to remember a password and provide stronger resistance to phishing. Organizations reviewing password policies should combine these protections with measures designed to secure single sign-on systems against credential attacks.

2. Treating Every Public Wi-Fi Network as Equally Dangerous

“Never use public Wi-Fi” was once common security advice. However, widespread adoption of HTTPS means that most websites now encrypt information travelling between a device and the website.

The US Federal Trade Commission says that connecting through public Wi-Fi is usually safe because most websites use encryption. Users should still check for HTTPS and remember that an encrypted connection does not prove that the website itself is legitimate. A phishing website can also use HTTPS.

Public networks continue to present risks. Attackers may create convincing lookalike networks, manipulate captive-portal login pages or target devices with outdated software and exposed sharing settings.

Instead of avoiding every public network, users should:

  • Confirm the network name with the venue before connecting.

  • Disable automatic Wi-Fi connections and unnecessary file sharing.

  • Keep the operating system, browser and security software updated.

  • Avoid proceeding past browser certificate warnings.

  • Use cellular data or a personal hotspot for especially sensitive work.

  • Follow an employer’s approved VPN requirements when accessing company systems.

A trusted VPN can provide another encrypted layer, particularly for work traffic or applications that do not protect their own connections. However, a VPN transfers trust from the local network to the VPN provider and does not prevent phishing, malware or account compromise.

3. Assuming Antivirus Software Is a Complete Security System

Antivirus software remains an important protection and should not be disabled. The outdated habit is assuming that installing it is the only step needed to secure a device.

Traditional antivirus products relied heavily on signatures that identified previously discovered malicious files. Modern security tools also use reputation checks, behavioural analysis, cloud intelligence and other methods to identify suspicious activity.

Attackers nevertheless use techniques intended to evade detection, including frequently changing malware, malicious scripts, abuse of legitimate system tools and attacks that leave few conventional files behind. Artificial intelligence may help criminals modify malicious code more quickly, but malware evasion existed long before generative AI.

CISA’s ransomware guidance recommends keeping antivirus and antimalware tools updated while also using protections such as application allowlisting and endpoint detection and response. This reinforces an important point: antivirus should be one part of a layered defence.

For individual users, that means enabling the device’s built-in or another reputable security product, installing software updates promptly, downloading applications from trusted sources and maintaining backups. Businesses should add centralized monitoring, restricted administrative privileges, application controls and tested recovery procedures.

Running multiple antivirus products at the same time is not necessarily safer. They may conflict, reduce performance or interfere with each other’s detection capabilities.

4. Believing Any Form of Two-Factor Authentication Is Unbreakable

Two-factor authentication remains one of the most effective ways to prevent account takeover, and users should enable it wherever possible. The mistake is believing that every form of two-factor authentication provides the same protection—or that it makes an account impossible to compromise.

Text-message codes and one-time passwords can be captured through phishing. Attackers may also send repeated login approval requests in the hope that a user eventually accepts one.

Another threat is session theft. After a successful login, a website generally creates a session token or cookie that allows the user to remain signed in. Malware or adversary-in-the-middle phishing infrastructure can steal this token and reuse it without repeating the original authentication process.

Microsoft explains that stolen browser cookies can bypass authentication controls. This is why infostealers that collect browser data and authentication tokens remain dangerous, as demonstrated by the growing capabilities of threats such as the REMUS infostealer.

Passkeys and physical security keys provide stronger protection against phishing because authentication is tied to the legitimate website. CISA recommends moving toward phishing-resistant MFA, especially for important or privileged accounts.

However, even passkeys cannot make an infected device completely safe. Users and organizations must also protect endpoints, monitor active sessions, revoke suspicious sessions and require fresh authentication before particularly sensitive actions.

Security Controls Must Evolve With the Threats

The lesson is not to abandon passwords, public Wi-Fi precautions, antivirus software or two-factor authentication. Each remains useful when applied correctly.

The safer approach is to replace scheduled password resets with unique credentials or passkeys, assess public networks based on the connection and activity, treat antivirus as one security layer and choose phishing-resistant authentication whenever possible.

Cybersecurity habits should evolve as attacks and defensive technologies change. A safeguard becomes dangerous when users stop examining what it protects against—and assume that it can protect them from everything.

Attackers Exploit CVE-2026-82329 to Forge JFrog Artifactory Admin Tokens



Cybersecurity researchers have observed attackers exploiting a critical JFrog Artifactory vulnerability shortly after its public disclosure. The flaw allows unauthenticated attackers to obtain administrative privileges on vulnerable self-hosted installations.

Tracked as CVE-2026-82329, the authentication-bypass vulnerability carries a CVSS severity score of 9.8. JFrog published its advisory and released security updates on August 28, 2026. Threat-intelligence researchers subsequently detected exploitation attempts beginning on September 1.

What Is JFrog Artifactory?

JFrog Artifactory is an artifact repository manager used by development teams to store, manage and distribute software packages and binary files.

Because Artifactory often connects directly to software-development and deployment pipelines, administrator-level access could allow attackers to manipulate repositories, steal credentials or introduce malicious components into software builds.

How CVE-2026-82329 Works

The vulnerability affects JFrog Access, the component responsible for authentication and credential management.

According to research shared by watchTowr, Artifactory installations without an additional join key configured may receive a fallback or “phantom” join key. Attackers can potentially abuse this condition to forge access and generate administrator-level authentication tokens.

Successful exploitation does not require an existing account or user interaction. An attacker only needs network access to a vulnerable Artifactory installation operating under the affected configuration.

The vulnerability does not directly provide remote-code execution. However, administrative control over an artifact repository could allow attackers to modify packages, create unauthorized accounts, access sensitive credentials and interfere with connected build systems.

Exploitation Detected in the Wild

WatchTowr researchers reported observing attackers use the vulnerability to generate administrator tokens and enumerate information about users, groups, credentials and federated-access configurations.

Some activity appeared limited to confirming whether a system was vulnerable. In a smaller number of cases, attackers reportedly created backdoor accounts and examined the compromised environment for opportunities to maintain access or expand the intrusion.

Researchers had not observed widespread scanning or mass exploitation when the activity was initially reported. Nevertheless, the rapid transition from public disclosure to exploitation demonstrates the limited time organizations have to secure internet-facing systems.

The Canadian Centre for Cyber Security has also warned that open-source reporting indicates active exploitation of CVE-2026-82329.

Patched JFrog Artifactory Versions

JFrog has released fixes across multiple supported Artifactory branches. Self-hosted customers should upgrade to the applicable fixed release:

  • 7.111.21

  • 7.117.28

  • 7.125.20

  • 7.133.29

  • 7.146.38

  • 7.161.20

JFrog says affected cloud environments have already been fortified and do not require customer action. Administrators of self-hosted deployments should consult the official JFrog security advisory to identify the correct update for their installation.

Recommended Security Measures

Organizations operating self-hosted JFrog Artifactory installations should:

  • Install the appropriate security update immediately.

  • Restrict internet access to Artifactory management interfaces.

  • Review audit logs for unexpected token or administrator-account creation.

  • Revoke unauthorized tokens and remove unfamiliar user accounts.

  • Rotate credentials and secrets accessible through the affected environment.

  • Inspect repositories for unauthorized package or configuration changes.

  • Examine connected CI/CD systems for evidence of lateral movement or artifact tampering.

CVE-2026-82329 is particularly dangerous because compromising a central artifact repository can affect more than the initially targeted server. Attackers with administrative access may be able to interfere with the software-development process and distribute modified components through trusted internal channels.

No public evidence currently confirms that CVE-2026-82329 is connected to the previously reported OpenAI and Hugging Face AI-agent activity involving an internal Artifactory environment. The two stories should be treated as separate security incidents.


FBI Investigates Dark Web Service Offering 153 Million Driver’s Licenses

 



The FBI has opened an investigation into an apparent breach involving identity verification provider IDScan.net after a newly launched dark web service began advertising access to more than 153 million U.S. and Canadian driver’s license records.

The service, named Nexus, appeared on the Russian cybercrime forum Exploit on August 31, claiming access to identity documents belonging to more than 170 million people across North America. Its advertised database includes more than 153 million driver’s licenses, over 10 million identification cards, more than three million travel or international identity documents, and at least 579,000 medical cards.

An examination of the service indicates that the claimed volume may be credible. A search without filters reportedly produced about 11.5 million pages of records, with approximately 15 results per page. Canadian licenses accounted for roughly 1.1 million results, including 473,673 records from Ontario, while most listings originated from the United States.

The dataset also contains marijuana dispensary cards, commercial driver’s licenses and records marked “CAC,” potentially referring to U.S. government Common Access Cards. Nexus operators claim the information is being obtained through an ongoing compromise of a major identity verification company serving Fortune 500 customers. They claim to have continuously extracted new records for more than a year.

Evidence examined by KrebsOnSecurity also indicates that the database may still be receiving stolen information. The number of available driver’s license records reportedly increased by nearly 400,000 within 24 hours.

The exposed records are unusually detailed. One license examined by Krebs contained six image files showing the front and back of the document, including standard, infrared and ultraviolet captures. Each file carried a timestamp. In several cases, those timestamps corresponded closely with victims’ real-world activities.

Krebs tested the apparent pattern by obtaining permission to search for licenses belonging to more than a dozen acquaintances. Nine licenses were located, and each individual confirmed travelling on or around the dates associated with the image timestamps. Further comparison with rental records indicated the timestamps appeared consistent with Greenwich Mean Time.

The evidence initially pointed toward airports, but that theory weakened because the database contained no passports and several individuals had not presented their licenses at airport security. Two federal employees who appeared in the dataset said they used other government identification at airport checkpoints, but later handed their state licenses to Hertz when renting vehicles.

A particularly revealing comparison involved Krebs’ own license and his mother’s. Their records carried timestamps only seconds apart, corresponding to the time both licenses were handed to a Hertz representative. Another exposed license belonged to security researcher Zach Edwards, whose timestamp matched a trip to Las Vegas for DEF CON. Edwards said he showed his license to TSA, his hotel and Planet 13, but identified the dispensary as the only location that definitely scanned it.

That connection is notable because Planet 13 announced in 2022 that it had deployed IDScan.net’s VeriScan technology across 16 check-in stations at its Las Vegas SuperStore. The system captures government-issued identification, performs document authentication and can use white-light, infrared and ultraviolet imagery. IDScan.net says its technology performs more than 21 million identity verifications each month across more than 20,000 locations.

IDScan.net also publicly lists major organizations using its technology, including Hertz, Target, FedEx and Caesars Entertainment. Its current platform supports ID scanning, document authentication, data parsing and integrations through APIs and software development kits.

IDScan.net told KrebsOnSecurity that it was investigating but had not provided a substantive public explanation of the suspected incident. Its documentation shows that its systems can retain raw files generated during scans, while its security documentation describes encryption for data at rest and in transit.

The FBI’s New Orleans field office subsequently opened an official investigation into the suspected breach. The development adds a law-enforcement dimension to an incident that could expose highly sensitive identity information at unprecedented scale.

The potential consequences extend beyond conventional credential theft. Driver’s license information is legally recognized as identifying information, and stolen identity data can be used to open accounts, obtain services, commit financial fraud or impersonate victims.

The incident also exposes a difficult security trade-off in modern identity verification. Organizations increasingly depend on third-party systems to scan government credentials for travel, rentals, retail, financial services and age verification. TSA began enforcing REAL ID requirements for domestic air travel in May 2025, further embedding government-issued identification into everyday verification processes.

For now, the precise intrusion path, affected customers and total number of compromised individuals remain unconfirmed. However, the combination of detailed document images, matching timestamps, apparent fresh data collection and the FBI investigation makes Nexus a serious warning about the risks created when sensitive identity documents are concentrated within third-party verification infrastructure.

NSA Warning Exposes Common Router Security Risks

 

The recent warning from the NSA and partner agencies highlights a simple but important reality: routers are often the weakest link in a home or small-office network. Attackers do not need a dramatic new exploit if a device is already exposing old services, default credentials, or remote management features that were never meant to be public. 

The advisory focused on enterprise networking gear, especially Cisco equipment, but the lessons translate well to consumer routers because the same habits create the same openings. In practice, the risk is not just about sophisticated nation-state operations; it is also about ordinary misconfiguration that leaves the door unlocked. 

One of the biggest problems is unnecessary services. Many routers can run SNMP, SSH, Telnet, FTP, USB file sharing, media-server functions, or other optional features, and every extra service increases the attack surface. If a feature was turned on for a one-time setup task and then forgotten, it should usually be disabled. The same caution applies to convenience features like WPS, which can make wireless access easier but can also weaken security if left enabled after setup. The safest rule is to keep only what you actively use and understand. 

Credentials and remote access are the next major concerns. A router’s admin password is separate from the Wi-Fi password, and the admin login protects the settings that control your DNS, firewall, port forwarding, and wireless configuration. If that password is still factory default, short, reused, or predictable, it should be replaced immediately with a unique one stored in a password manager. It is also wise to disable remote management unless you truly need it, because exposing the admin interface to the public internet greatly increases the chance of abuse. If remote access is necessary, a VPN and multi-factor authentication are much safer options. 

Keeping firmware updated is just as important. Router updates often fix security flaws the same way phone or PC updates do, but many people never check whether automatic updates are enabled or whether their device still receives support. If a router has stopped getting patches, it becomes a growing liability because known and newly discovered vulnerabilities can accumulate over time. End-of-life hardware should be replaced rather than trusted indefinitely. For most homes, that means a quick review of services, passwords, remote access, and firmware status can eliminate the most common router risks.