Prompt injection, where malicious instructions are embedded in content processed by an AI model, remains a frontier security challenge. Lockdown Mode is specifically engineered to disrupt the final stage of a prompt injection attack: the unauthorized transfer of sensitive data to an attacker-controlled destination via outbound network requests.

Importantly, Lockdown Mode does not prevent prompt injections from entering the model’s context. A malicious payload embedded in a cached webpage, an uploaded PDF, or any other ingested content can still influence model behavior and response accuracy. The feature focuses exclusively on blocking the exfiltration pathway, not the injection vector itself.

ChatGPT Lockdown Mode

When Lockdown Mode is active, the following ChatGPT capabilities are restricted:

• Live web browsing — Limited to cached content only; results may be stale or unavailable
• Image retrieval — ChatGPT cannot fetch or display web-derived images in responses
• Deep research — Fully disabled
• Agent mode — Fully disabled
• Canvas networking — Users cannot approve Canvas-generated code to make network requests
• File downloads — ChatGPT cannot download external files for data analysis; manually uploaded files remain accessible

Memory, file uploads, conversation sharing, and model training settings are not affected by Lockdown Mode and remain independently configurable.

OpenAI classifies app and connector configurations into risk tiers for Lockdown Mode environments:

• High risk: Read or write actions for untrusted apps; write actions for trusted apps with broad or uncertain visibility; both are explicitly not recommended.
• Medium risk: Sync connectors and read actions for trusted apps carry lower exfiltration sink risk but can still expose sensitive source data.
• Lower risk: Write actions for trusted apps are only permissible when side effects are confirmed to be visible only to trusted parties.

For managed workspaces, Lockdown Mode does not automatically disable all connected apps. Administrators must manually configure role-based access controls (RBAC), assign trusted apps, and audit connector permissions to achieve meaningful protection.

Enterprise workspace admins can enforce Lockdown Mode by creating a custom role designated as a “Lockdown Mode” role and assigning members or groups to it.

The Compliance API Logs Platform provides persistent audit visibility into app usage, shared data, and connected sources independent of Lockdown Mode status.

Notably, Lockdown Mode and Developer Mode are mutually exclusive; enabling one automatically disables the other. Additionally, Lockdown Mode has no effect on Codex network access.

OpenAI acknowledges that Lockdown Mode does not guarantee complete protection. Residual risk exists through enabled third-party apps, unforeseen capability combinations, and novel exploitation techniques. Prompt injections hidden in uploaded files can still cause incorrect or manipulated AI responses even with Lockdown Mode active.

Personal and self-serve Business users can enable the feature via Settings → Security → Advanced Security → Lockdown Mode. Enterprise admins should consult OpenAI’s RBAC documentation and Compliance API guidance for workspace-wide deployment.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates.

The post New ChatGPT Lockdown Mode to Mitigate Prompt Injection and Data Exfiltration Attacks appeared first on Cyber Security News.

The culprit is an SDK developed by Bright Data, a Tel Aviv-based data-collection company that markets what it calls the world’s largest residential proxy network, claiming 150M+ IP addresses sourced via embedded software in partner apps.

When installed, the SDK silently transforms a user’s connected TV (CTV) or mobile device into an exit node, routing paying customers’ web-scraping traffic through the user’s home internet connection.

Researcher Buchodi, working alongside Include Security, explains why connected TVs are a prime target compared to smartphones: they are always plugged in, always on Wi-Fi, sit in standby 24/7, face virtually zero corporate or MDM oversight, and are rarely attended by users.

Free Apps Turning Smart TVs into Proxies

The SDK’s configuration confirms this exploitation, with idle threshold flags set to ignore_screen_on: true and ignore_on_call: true meaning a device is considered eligible to relay third-party traffic even while a user is actively watching or on a call.

The monthly bandwidth default for Wi-Fi relaying is capped at 200 GB per device, according to config values retrieved from Bright Data’s own unauthenticated public endpoint at clientsdk.bright-sdk.com.

The same unauthenticated config endpoint exposes a partner manifest, which researchers identified as including:

• PlayWorks Digital — 400+ CTV game titles distributed across Samsung, LG, Comcast, Roku, and Sky, reaching an estimated 250 million TV households
• CloudTV — integrated across 125+ TV brands and 15+ OEMs
• Viber Media (Rakuten) — 250M–820M monthly active users
• Moonfrog Labs — ~10M MAU on Teen Patti Gold alone
• Hola Networks — Bright Data’s lineage parent company

The SDK opens a persistent WebSocket to proxyjs.brdtnet.com:443, resolving to AWS Global Accelerator IPs and presenting a TLS certificate for *.luminatinet.com Bright Data’s pre-2018 corporate name was Luminati Networks.

This legacy hostname serves as a direct detection pivot for defenders: any luminatinet.com or brdtnet.com traffic on a network is specifically the SDK’s peer-tunnel plane, not legitimate Bright Data customer traffic.

Critically, the SDK uses Apple’s NWParameters.requiredInterface API to bind the data plane directly to the physical Wi-Fi or cellular interface, bypassing any user-configured VPN entirely.

The control plane uses CFHTTPMessage primitives instead of URLSession, defeating standard iOS instrumentation tools. The combination ensures the SDK’s most sensitive channel remains invisible to typical security monitoring layers.

Buchodi recommends blocking the following DNS hostnames at your router:

• proxyjs.brdtnet.com
• proxyjs.luminatinet.com
• clientsdk.bright-sdk.com

For TLS-based filtering, drop any handshake with SNI matching *.brdtnet.com, *.luminatinet.com, or *.luminati.io. Enterprise MDM administrators should scan for Swift binary symbols BrdWebSocketFacade and BrdNetwork.DNSResolver to identify affected apps on managed devices.

Include Security notified Bright Data on May 11, 2026, via privacy@brightdata.com. No response was received prior to publication.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates.

The post Free Apps on Samsung and LG Smart TVs Secretly Turning Your Devices Into AI Proxies appeared first on Cyber Security News.

Tracked as CVE-2026-28318, the vulnerability affects SolarWinds Serv-U file transfer software and enables unauthenticated attackers to crash the service through specially crafted HTTP requests.

CVE-2026-28318 is classified as an Uncontrolled Resource Consumption flaw (CWE-400), a vulnerability class where an application fails to properly limit the resources it allocates in response to incoming input.

In this case, an attacker can send a malicious POST request using the Content-Encoding: deflate HTTP header, forcing the Serv-U service to consume excessive resources and crash without requiring any authentication credentials.

The attack vector is particularly alarming because it requires zero privileges and can be triggered remotely over the network. This makes it an attractive initial-access vector for threat actors targeting organizations that expose Serv-U services to the internet.

CISA added CVE-2026-28318 to the KEV catalog on June 5, 2026, setting a remediation deadline of June 19, 2026 for all Federal Civilian Executive Branch (FCEB) agencies. Under Binding Operational Directive (BOD) 22-01, federal agencies are mandated to remediate KEV-listed vulnerabilities within the specified timeframe.

Whether the vulnerability has been leveraged specifically in ransomware campaigns remains unknown at this time, though CISA urges all organizations, not just federal entities, to treat this with high urgency given active exploitation in the wild.

Affected Products and Patch Availability

SolarWinds has released a hotfix addressing the vulnerability in Serv-U version 15.5.4 Hotfix 1. Organizations running any prior version of Serv-U are considered vulnerable and should apply the patch immediately.

SolarWinds published the advisory through its Trust Center, and full technical details are available via the NVD entry for CVE-2026-28318.

• Apply the SolarWinds Serv-U 15.5.4 Hotfix 1 patch immediately
• Restrict Serv-U service exposure by placing it behind a firewall or VPN where feasible
• Monitor logs for anomalous POST requests containing Content-Encoding: deflate headers
• Disable or decommission Serv-U instances if patching is not immediately possible
• Follow BOD 22-01 guidance for cloud-hosted Serv-U deployments

Security teams should consult the official SolarWinds advisory and NIST NVD entry for the latest technical details and patch guidance.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates.

The post CISA Warns of SolarWinds Serv-U Vulnerability Exploited in Attacks appeared first on Cyber Security News.

That’s where safe, controlled DDoS simulations come in. By launching the traffic ourselves, we verify scrubbing tiers, surface bottlenecks, and rehearse incident-response playbooks long before attackers show up.

Plenty of online “stressers” promise easy thrills, but most are illegal or unsafe. Only a handful of vetted providers can run large-scale tests without violating cloud policies. One standout is Red Button’s DDoS testing, an AWS-approved service that turns a potential nightmare into a structured fire-drill—complete with kill switches, live coaching, and audit-ready reports.

Over the next few minutes, we’ll explain how we ranked the five best DDoS-simulation platforms for 2026, why each one earned its spot, and how to run a test that proves value without risking production.

What is simulated DDoS testing and why it matters

When we say “DDoS simulation,” we mean a controlled attack that targets our own infrastructure.

Instead of waiting for criminals to swamp bandwidth, we spin up distributed traffic generators that mimic real botnets. They hammer every layer, from raw UDP floods to sneaky HTTP/2 reset bursts, while dashboards light up and the mitigation stack earns its paycheck.

Think of it as a fire drill for uptime. We find choke points, verify that rate-limits fire, and practice the call tree long before trouble starts. One dry run often exposes hidden dependencies a routine load test never touches, such as an overlooked DNS endpoint or a TLS termination node that stalls during handshake storms.

This practice is no longer optional. European regulators expect critical companies to prove resilience, and the U.S. SEC requires public firms to disclose material cybersecurity incidents within four business days. If you can hand auditors a report showing that a 150 Gbps onslaught left customers unaffected, compliance meetings run much smoother.

Cloud realities add another twist. AWS and Azure forbid self-run floods from customer instances; they allow tests only through approved partners. Using the right tool keeps you safe and keeps your cloud provider happy.

Most of all, simulated DDoS drills build confidence. Once you see your scrubbing service handle a deliberate 50 Gbps wave, the next headline-grabbing attack feels like a routine smoke alarm: loud but already managed.

How we picked the winners

Ranking DDoS-simulation platforms is not a beauty contest. We built a scoring sheet that weights the factors practitioners care about most, then let the numbers speak.

Safety and compliance came first. A simulated attack only helps if it stays under control, so we scored each vendor on kill switches, gradual ramp-up options, and official cloud-provider approval.

Next we graded attack realism. The strongest tools copy modern threats, from UDP carpet-bombing to the HTTP/2 reset trick that broke records last year. Breadth of vectors, update cadence, and the ability to mix L3, L4, and L7 traffic all increased the score.

Firepower still matters, so we measured peak scale and geographic spread. Can the service push hundreds of gigabits, or even terabits, from multiple regions, or does it top out in one data center?

A drill without usable feedback is just noise, so we tracked reporting depth. We wanted to see how fast each platform turns packet chaos into an executive-ready story and clear fixes.

Finally, we looked at ease of use, vendor credibility, and pricing flexibility. Self-service portals earned points for speed, while hands-on guidance helped teams new to DDoS drills. Long track records and solid value nudged scores higher.

Everything rolled into a 100-point scale. The five tools you will meet next rose to the top by keeping tests safe, realistic, and richly informative, without draining the budget or the network.

1. Red Button – best for expert-guided DDoS drills

Red Button’s DDoS testing is an authorized AWS and Azure partner that treats a DDoS drill like a surgical procedure, combining meticulous planning, precise execution, and zero surprises.

Each engagement starts with a discovery workshop. The Red Button team works with you to map critical paths, agree on stop metrics, and craft an attack plan that mirrors real adversary tactics. On test day, Red Button engineers join your war-room bridge and talk through each traffic ramp while your dashboards light up. If latency or errors edge past the red line, they cut the flow within seconds.

That expertise is backed by power. The cloud attack network can reach about 300 Gbps across more than 100 vectors, enough to mimic ransom-grade botnets without exposing bystanders.

Red Button is one of the few providers approved by both AWS and Azure for live DDoS simulations. Because the test is pre-cleared under provider policy, you avoid last-minute tickets to the cloud abuse desk.

Afterward, you receive more than raw graphs. The report pairs packet captures with an executive resiliency score, prioritized fixes, and evidence you can share with regulators or the board. You can even buy the service through AWS Marketplace, which simplifies procurement for large teams.

Pricing is premium, but one well-run drill can reveal the single configuration slip that would have taken you offline on Black Friday. For banks, SaaS providers, and critical infrastructure, Red Button offers the safest route to stare down a 300-gig flood without flinching.

2. RedWolf Security – best self-service platform with massive scale

Sometimes you need to run a DDoS drill at 2 a.m. without waiting weeks for a consultant. That need defines RedWolf.

After you log in, pick from more than 300 attack vectors, set a peak bandwidth, choose launch regions, and schedule the blast. The portal feels like a DevOps dashboard, not a ticketing queue, so you stay in control from first packet to wrap-up.

Power is the headline. The distributed cloud engine can deliver multi-terabit floods, letting you push telecom-grade defenses instead of guessing whether they hold past 200 Gbps. Traffic ramps up in controlled phases, and an automatic kill switch cuts flow within ten seconds if error rates exceed your limits.

Live graphs draw the attack in real time. If you see a choke point—for example, a regional load balancer struggling at 600,000 requests per second—you can change vectors or double the rate to confirm the weakness. Few platforms grant that level of real-time control.

When the run ends, a same-day report combines attack telemetry with your own logs. You see exactly when Shield, the WAF, or rate-limits engaged, along with practical recommendations for tightening settings before the next drill.

Pricing is flexible. Choose a usage-based subscription for monthly tests or a pay-per-event bundle for big-bang drills. Either way, you avoid consultant lead-times and pay only for the traffic you generate.

For organizations that need frequent, high-scale, self-directed drills, RedWolf turns the DDoS test range into a push-button experience.

3. NimbusDDOS – best for white-glove team training

If Red Button feels like a surgical strike and RedWolf a firing range, NimbusDDOS serves as a live-action coach.

Preparation begins with a deep-dive call where Nimbus maps your tech stack and, more importantly, your playbooks. They learn who carries the pager, how alerts escalate, and where past incidents went sideways. The resulting plan focuses less on raw bandwidth and more on exercising every muscle in your incident-response process.

On game day, a Nimbus engineer joins your war room. They announce each attack phase, watch dashboards with you, and adapt in real time. Quench a 100 Gbps SYN flood faster than expected? They shift to an application-layer barrage or add DNS amplification to keep the pressure high. The session feels like a cyber scrimmage complete with mid-play feedback.

Because a human guides the traffic, safety stays high. The moment latency or errors cross agreed thresholds, the operator dials back the flow to stress systems without harming customers.

The payoff appears in the post-mortem. Nimbus delivers a granular timeline that pairs attack vectors, mitigation triggers, and human reactions. You see exactly when Shield engaged, when the SOC paged DevOps, and how long it took to update the status page. The report reads like a sports replay, highlighting wins, pointing out hesitations, and recommending drills to trim seconds off your next response.

Engagements are priced per scenario, so costs rise with ambition. For organizations that value muscle memory as much as hardware validation, Nimbus turns a DDoS simulation into a training camp the whole team can learn from.

4. Keysight BreakingPoint & CyPerf – best DIY lab solution

Sometimes you need a private wind tunnel, not an outdoor storm. Keysight’s BreakingPoint hardware and CyPerf software provide exactly that, a repeatable in-house DDoS laboratory you can activate whenever code or infrastructure changes.

BreakingPoint is a rack-mount appliance that pushes traffic at line rate, up to about 150 Gbps per chassis and terabit levels when you cluster units. CyPerf extends the same engine to virtual agents that you deploy across cloud regions. Together they create a controllable “friendly botnet,” blending more than 36,000 attack signatures with legitimate user flows to see how gear responds under mixed stress.

The tooling excels in pre-production. Need to certify a new firewall, WAF rule set, or Kubernetes ingress before customers touch it? Launch a scripted scenario: nine seconds of HTTP/2 resets, a one-second pause, then a UDP carpet bomb. Run it today, tune configs, run it again tomorrow; the load stays identical, giving true apples-to-apples results.

Because tests remain inside your lab VLAN or approved cloud accounts, you avoid provider abuse desks. You are free to capture every packet, feed results into CI pipelines, and schedule nightly “chaos bursts” that catch regressions before they reach production.

The trade-off is ownership. Licenses require real capital, and someone on your team must learn the console, craft scenarios, and maintain the attack library subscription. If you run a drill only once a year, a managed service is cheaper. For telcos, appliance vendors, or enterprises committed to continuous validation, Keysight offers unrivaled autonomy, scale, and depth.

5. Cyttack.ai – best emerging SaaS for quick, budget-friendly drills

Not every company needs terabit storms or a live coach. Some just want a fast, affordable check that proves their WAF and rate limits are in the right ballpark. Cyttack.ai fills that gap with an AI-guided SaaS built for lean security teams.

Signup feels like onboarding any cloud app. A wizard asks about your stack, expected peak traffic, and current mitigations. Behind the scenes, Cyttack’s model turns those answers into a right-sized attack plan, usually between 20 and 100 Gbps across the most relevant vectors. Choose a time window, click launch, and watch real-time charts track latency and error rates. A bright Stop button remains visible for instant abort.

The value appears in the post-test email, delivered minutes after the flood ends. It summarizes results in plain language, then offers prescriptive fixes like sample WAF rules, nginx rate-limit snippets, and Terraform blocks for scaling thresholds. It feels less like a generic report and more like a junior consultant whispering next steps.

Cyttack’s tiered pricing is equally friendly. Plans start at a few hundred dollars per month for several drills, while higher tiers raise traffic ceilings and add API access for CI integration. Chat support is available during test windows, but there is no on-call engineer, so the platform suits teams comfortable reading their own metrics.

Is it perfect? No. The startup lacks decade-long case studies and tops out below triple-digit gigabit floods. Still, for SaaS companies, fintech startups, or regional enterprises priced out of traditional services, Cyttack shifts DDoS testing from a scary budget line to an approachable, repeatable habit.

Quick comparison at a glance

You have met the contenders. Before we continue, here is a side-by-side snapshot that distills pages of specs into one fast read.

Use this table to match your risk profile to the right tool. If you test quarterly and want hands-on guidance, Red Button or Nimbus make sense. If you test weekly and need autonomy, RedWolf or Keysight may fit better. When budget is tight but diligence counts, Cyttack keeps the door open without draining the wallet.

Honorable mentions and niche options

The Top 5 cover most enterprise needs, yet a few niche players still deserve a quick spotlight.

MazeBolt RADAR specializes in non-disruptive “micro-attacks.” Instead of one big bang, the platform fires low-Gbps probes around the clock to find configuration gaps without risking downtime. It suits teams that cannot schedule maintenance windows but still want continuous assurance.

LoDDoS splits the difference between self-service and white-glove. You design tests in a web console while LoDDoS engineers shadow the run in real time, ready to throttle traffic if KPIs wobble. The model is safe and flexible, though subscription costs edge toward premium.

Finally, there are the classic open-source flooders such as LOIC, hping3, and Slowloris. They work for a lab demo on a Friday afternoon, but remember they launch from a single host, lack kill switches, and can break provider terms in a heartbeat. Use them only inside isolated networks, never on production infrastructure.

If your needs fall outside mainstream tooling—for example, 24/7 low-impact validation or a human safety net on a tight budget—these alternatives might fill the gap. Weigh their limits carefully before betting uptime on them.

How to choose the right DDoS testing tool for your needs

Start with a simple question: What are we trying to prove?

If your board wants hard evidence that production can survive a ransom-grade flood, a fully managed drill with Red Button or Nimbus offers the most credibility. Their experts control the blast, capture every metric, and hand you an audit-ready report.

Maybe you ship code weekly and need repeatable regression tests. In that case, self-service muscle like RedWolf or a lab appliance from Keysight fits better. You can run scenarios whenever a new microservice rolls out, catch regressions fast, and avoid scheduling headaches.

Budget matters, yet focus on value per insight, not sticker shock. A single unmitigated outage can cost millions. If funds are tight, start small with Cyttack’s SaaS tier or a MazeBolt continuous probe, then scale up once leadership sees the payoff.

Skill sets also matter. If your team lacks deep DDoS expertise, vendor guidance is safer than flying solo. Conversely, if you already operate large scrubbing centers, you may crave full control and packet visibility.

Finally, respect your environment. Cloud workloads require provider-approved partners, while on-prem labs grant more freedom. Map your constraints first, then shortlist only the tools that meet every compliance box.

Cover those five checkpoints—objective, frequency, budget, expertise, and environment—and the best choice usually reveals itself.

Safety, ethics, and legal considerations

Launching a DDoS test without guardrails is like lighting fireworks in a server room. It feels exciting until something ignites.

First, get written permission from every stakeholder: hosting providers, upstream ISPs, cloud accounts, and business owners. AWS and Azure forbid self-run floods; they allow tests only through approved partners. Skip this step and your simulation could end with account suspension or worse.

Second, define a clear scope. List target IPs and domains, set traffic ceilings, and agree on kill thresholds for latency, error rate, or CPU load. Share the plan with support teams so no one mistakes the drill for a real attack.

Third, schedule tests during low-traffic windows and monitor everything. Keep the NOC, SOC, customer support, and comms on the same bridge. If metrics spike beyond plan, hit the kill switch at once. A good provider or tool makes that a single click.

Fourth, never borrow firepower from shady “booter” services. Many rely on hijacked IoT devices, and paying them funds criminal operations. Use reputable platforms that generate traffic from infrastructure they own or lease.

Finally, record the exercise. Packet captures, timeline logs, and chat transcripts create proof of due diligence for auditors and cyber-insurance claims. After the test, run a blameless review, patch gaps, and schedule the next drill. Safety is not a checkbox; it is a habit.

Best-practice tips for high-value drills

Treat every simulation like game day. Place monitoring dashboards front and center, set clear success metrics, and time how long it takes for the first alert to appear and the first human to act.

Start small and ramp up. A gentle 1 Gbps warm-up confirms that routing, logging, and kill switches behave as expected. Once confidence builds, raise traffic in phases until you reach your agreed ceiling.

Blend traffic types. Attackers seldom rely on one trick, so pair a volumetric flood with an application-layer hit or a DNS amplification burst. Seeing how your stack handles mixed vectors is more revealing than a single-flavor blast.

Capture everything. Packet traces, WAF logs, CPU graphs, and call recordings provide richer insight later. Label files with UTC timestamps so timelines align across teams.

Hold a blameless post-mortem within 24 hours. Celebrate fast wins, catalog slow reactions, and assign owners to every fix. Schedule the next test before memories fade; repetition turns lessons into muscle memory.

Finally, close the loop. Patch configurations, update runbooks, and rerun the same scenario to verify improvements.

Conclusion

A DDoS drill ends only when you can prove the next flood will hurt less. Whether your team needs bespoke expert guidance (Red Button), self-service firepower (RedWolf), white-glove coaching (NimbusDDOS), an in-house lab (Keysight BreakingPoint / CyPerf), or a budget-friendly SaaS check (Cyttack.ai), the right platform turns an unknown risk into a measurable, repeatable rehearsal.

Start small, blend attack vectors, capture every metric, hold a blameless post-mortem, and close every gap before the next test. Done well, simulated DDoS testing transforms the next real flood from an emergency into a routine event your stack — and your people — have already survived a dozen times in dashboards, runbooks, and muscle memory.

The post Top 5 Best Tools for Simulated DDoS Attacks in 2026 appeared first on Cyber Security News.

The flaw exposes a significant supply chain risk in one of the most widely used machine learning frameworks, impacting developers, enterprises, and AI pipelines globally.

The vulnerability stems from improper handling of untrusted data in model configuration files, specifically in the _attn_implementation_internal attribute.

Attackers can inject this field into a model’s config.json, causing the library to load and execute arbitrary Python code during the standard model loading process.

This occurs even when the security control trust_remote_code=False is enforced, effectively bypassing a key protection mechanism.

HuggingFace Flaw Enables RCE

The issue affects Transformers versions 4.56.0 through 5.2.x when used with the optional kernels package.

The vulnerable code path was introduced in August 2025. It remained exploitable until March 2026, creating an exposure window of approximately six months.

During this period, any user loading a malicious model from HuggingFace Hub using the common from_pretrained() function could be silently compromised.

In a typical attack scenario, a threat actor uploads a seemingly legitimate model to HuggingFace Hub. The model includes a crafted config.json file that contains the malicious _attn_implementation_internal field, which points to an attacker-controlled repository.

When a victim loads the model, the Transformers library automatically downloads and imports the referenced code without validation or sandboxing. This leads to immediate code execution on the victim’s system.

Successful exploitation enables attackers to access sensitive data, including AWS credentials, SSH keys, API tokens, and environment variables.

It also enables persistence mechanisms, lateral movement across infrastructure, and potential compromise of CI/CD pipelines.

Because the attack executes during normal model loading, it produces no warnings or visible indicators, making detection extremely difficult.

The scale of impact is substantial. The Transformers library has over 2.2 billion installs and processes approximately 146 million downloads per month.

With more than one million models hosted on HuggingFace Hub, the attack surface is extensive. During the exposure period, an estimated 232 million installations were vulnerable, increasing the likelihood of real-world exploitation.

Researchers at Pluto Security noted that the vulnerability highlights a broader issue in machine learning ecosystems: treating model files and configurations as trusted inputs.

Similar patterns have been observed in other frameworks, where “safe” modes fail to prevent code execution because internal pathways are not fully accounted for.

HuggingFace addressed the issue in version 5.3.0 by blocking unsafe internal attributes during configuration parsing and enforcing stricter controls on kernel loading.

The fix also ensures that external code execution requires explicit user consent via trust_remote_code=True. Organizations using Transformers are strongly advised to upgrade to version 5.3.0 or later immediately.

Additionally, teams should audit previously downloaded models, monitor for suspicious outbound connections, and isolate model execution environments to reduce risk.

CVE-2026-4372 underscores the growing importance of securing AI supply chains. As machine learning adoption accelerates, attackers are increasingly targeting model distribution platforms, turning trusted workflows into high-impact attack vectors.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates.

The post Critical Hugging Face Transformers Vulnerability Enables Remote Code Execution Attacks appeared first on Cyber Security News.

Maintained by Sonu Kapoor and backed by the same organization behind the OWASP Top 10, the tool addresses a longstanding gap in developer security workflows: the absence of fast, actionable, local-first remediation guidance.

OWASP CVE Lite CLI Tool

Most security scanners are built for pipelines, not people. Tools like Dependabot file pull requests, developers get to “eventually,” CI scanners block merges hours after code is reviewed, and security dashboards surface lists of CVE IDs with no clear path to resolution. The result is alert fatigue; developers learn to tune out the noise.

CVE Lite CLI takes a different approach: it runs at the moment just before a developer pushes code, producing a concrete remediation plan rather than just a list of vulnerability identifiers.

As OWASP noted, “the goal is to make dependency security part of the everyday developer workflow, not just a CI check or enterprise-only concern.”

CVE Lite CLI reads a project’s lockfile locally and queries the Open Source Vulnerabilities (OSV) database for advisory data. It supports all four major JavaScript package managers, npm, pnpm, Yarn, and Bun, and produces copy-and-run install commands scoped precisely to whichever one a project uses. Critically, nothing leaves the developer’s machine: no source code, no dependency tree, no credentials.

The tool distinguishes between direct and transitive dependencies, a nuance most free scanners miss. For transitive findings, it goes further by identifying whether a simple npm update <parent> resolves the vulnerable child within the current version range, or whether the parent package itself needs a major upgrade.

• Remediation-first output — every finding includes a validated, copy-and-run fix command, not just a CVE ID.
• Usage-aware reachability (--usage) — static analysis detects whether vulnerable packages are actually imported in source code, cutting false-positive noise.
• Offline advisory DB — sync ~217,065 advisory records in under 9 seconds for air-gapped or enterprise environments using cve-lite advisories sync.
• Interactive HTML report (--report) — generates a self-contained dashboard with severity cards, a searchable findings table, and copy-ready commands.
• Auto-fix mode (--fix) — applies validated direct dependency fixes using the detected package manager, then rescans automatically.
• CI/CD integration — --fail-on high exits non-zero on threshold breaches; --sarif writes SARIF 2.1.0 output for GitHub Code Scanning; --cdx generates a CycloneDX 1.4 SBOM.
• AI assistant integration (install-skill) — writes skill files for Claude Code, Codex CLI, Gemini CLI, Cursor, and GitHub Copilot so AI assistants can analyze scan output and generate prioritized fix plans.

The tool can be cloned from GitHub. Installation takes a single command with no account, no configuration, and no data leaving the machine:

bashnpm install -g cve-lite-cli
cve-lite /path/to/project

Or as a one-off scan via npx:

bashnpx cve-lite-cli /path/to/project

The attached scan output above illustrates a real-world result — 39 vulnerable packages detected across 1,620 parsed dependencies, with 3 critical findings including jsonwebtoken@0.1.0 (transitive, fix via express-jwt upgrade) and marsdb@0.6.11 (direct), alongside a prioritized top fix command ready to run immediately.

Being accepted as an OWASP Incubator Project means CVE Lite CLI has been peer-reviewed by security professionals and operates under vendor-neutral, community-driven governance.

The tool has been validated against real-world codebases, including OWASP Juice Shop, Visual Studio Code, NestJS, Ghost CMS, Gatsby, Storybook, and the Vercel AI SDK, and has documented scans with real findings, not demos.

CVE Lite CLI has a minimal runtime footprint of just four dependencies (yaml, yarn-lockfile, better-sqlite3, fflate), keeping it auditable and lightweight by design, a deliberate choice for a security-oriented tool.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates.

The post OWASP CVE Lite CLI – New Tool to Scan for Vulnerabilities in Your Projects appeared first on Cyber Security News.

The outage began at 8:08 PT / 15:08 UTC on June 5, 2026, when Anthropic’s status page flagged elevated errors across several Claude models. An investigation was immediately launched, with Anthropic confirming disruptions across claude.ai, the Claude API (api.anthropic.com), Claude Code, and Claude Cowork services.

Recovery was staggered across model versions, according to Anthropic’s official status page:

• Opus 4.6 — recovered at 15:25 UTC
• Sonnet 4.6 — recovered at 16:23 UTC
• Opus 4.8 — recovered at 16:59 UTC
• Opus 4.7 — recovered at 17:12 UTC
• Opus 4.5 — recovered at 17:29 UTC

Full service restoration was confirmed by 18:27 UTC (6:28 p.m. UTC), with Anthropic stating: “Success rates across all models have returned to expected levels. We are continuing to monitor closely to ensure no further issues will recur.”

Anthropic engineers attributed the outage to infrastructure issues rather than a security breach, and as of 5:00 p.m. EDT, the company had not confirmed any customer data exposure.

However, the incident echoes prior security concerns. A January 2026 GitHub advisory documented a vulnerability in Claude Code’s project-load flow that allowed malicious repositories to exfiltrate Anthropic API keys.

This is not an isolated event. Anthropic’s Claude platform has experienced multiple outages throughout 2026, including a notable networking-related disruption in March affecting Opus 4.6 and Sonnet 4.6, and a worldwide outage in May 2026.

Claude.ai currently reports 99.3% uptime over the past 30 days, though security analysts warn that an AI system’s single-vendor dependency creates dangerous single points of failure.

Organizations integrating Claude API into production pipelines should consider the following mitigations in light of this incident:

• Implement exponential backoff and retry logic for API calls to handle elevated error states gracefully.
• Deploy AI-specific observability tooling to track token throughput anomalies and regional error spikes.
• Audit single-vendor AI dependencies and architect fallback model routing across providers.
• Monitor for cross-tenant data anomalies in inference outputs, especially during known degradation windows.

The incident underscores the growing challenge AI providers face as demand for large frontier models intensifies, where infrastructure strain can blur the line between performance degradation and potential data integrity failures.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates.

The post Anthropic’s Claude Services Down — claude.ai, Claude Code, and Cowork Affected [Updated] appeared first on Cyber Security News.

The package, named “parsimonius,” was crafted to look almost identical to the widely used “parsimonious” library, a popular Python tool for building expression grammar parsers.

The single missing letter was no accident. It was a calculated move designed to trick developers into installing the wrong package without realizing it.

The attack relied on a technique called typosquatting, where a threat actor registers a package name that closely resembles a trusted one.

To make things worse, the attacker assigned the malicious package a version number that appeared newer than the legitimate release.

This made developers even more likely to install it, especially those relying on automated dependency resolution or who simply did not verify the full package name before clicking install.

Security analysts at Zscaler ThreatLabz identified the malicious package and shared their findings in a report with Cyber Security News (CSN).

According to the report, the package had already been downloaded 2,474 times before it was pulled from the repository.

That number, reached within just a matter of days, highlights how quickly supply chain attacks can cause widespread exposure across developer environments.

What made this campaign particularly crafty was how the attacker masked the malicious intent. The package actually included the real parsimonious parsing functionality, so developers using it would see completely normal behavior on the surface.

Underneath that legitimate facade, however, a Telegram-based backdoor was silently being deployed across every affected system.

Once the backdoor was active, attackers gained remote access to compromised environments and could harvest sensitive data directly from victims.

Their focus was specifically on .env files and bot authentication tokens, both of which are commonly packed with credentials, API keys, and secrets that open doors to much wider infrastructure access.

Hackers Publish Malicious Python Package

The malicious package was set up to operate on two levels at the same time. On the visible level, it behaved like a fully working parser library, keeping developers completely unsuspicious during normal use.

On the hidden level, it established communication with a Telegram bot, using the messaging platform as a command and control channel to receive instructions and quietly send stolen data out of the environment.

Using Telegram as a backdoor channel is a growing trend among threat actors because the platform is widely trusted and its traffic is far less likely to be flagged by standard network monitoring tools.

This makes it an attractive option for data exfiltration without triggering security alarms. Once established, the backdoor gave the attacker persistent remote access to every system where the package had been installed.

The version number was also chosen strategically. By setting it to appear more current than the real parsimonious package, the attacker increased the odds that automated tools or developers searching for the latest release would pull the malicious version without a second look.

Telegram-Based Backdoor and Data Theft Risks

The data targeted in this campaign was far from random. Focusing on .env files and bot tokens points to a deliberate effort to access broader infrastructure.

A single stolen .env file can expose database passwords, cloud service credentials, and secret keys that let attackers move laterally across entire systems or connected services.

Bot authentication tokens are equally dangerous in the wrong hands. Attackers who obtain them can take full control of bots embedded in business workflows, automated pipelines, or customer-facing services.

The downstream damage from that level of access can extend well beyond the original compromised machine.

Developers are strongly encouraged to always verify the exact spelling of any package name before installation. Using dependency audit tools that flag suspicious or newly registered packages adds a meaningful layer of defense.

Organizations should also rotate credentials immediately if a supply chain compromise is suspected and limit what sensitive data lives inside .env files in the first place.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.

The post Hackers Publish Malicious Python Package Mimicking Legitimate Parsimonious Parser appeared first on Cyber Security News.

This shift is reshaping how attacks unfold, and the numbers are hard to ignore. According to ANY.RUN’s Q1 2026 Cyber Risk Report, based on over 2.1 million malware and phishing investigations, three trends are redefining the threat landscape.

Credential theft climbed by 14.7%, loader-based attacks spiked by 98.3%, and Living-off-the-Land Binary and Script attacks leveraging JavaScript surged by 58.4%. These figures describe attackers who are becoming quieter and faster at the same time.

Analysts at ANY.RUN noted that the growing reliance on trusted tools is making attacks much harder to detect. When attackers use the same software administrators rely on to run their systems, traditional signature-based detection often fails to raise an alarm.

The challenge is no longer just finding malicious files but understanding whether a normally safe tool is being abused.

ANY.RUN said in a report shared with Cyber Security News (CSN) that early-stage compromise is one of the most overlooked risks in modern security operations.

The report found it takes just 21 seconds for an attacker to establish persistence after initial access, and only 16 seconds for Living-off-the-Land execution to begin. These margins do not allow a slow response.

The broader concern is that the gap between infection and full system compromise is narrowing fast. Security teams not equipped to investigate threats in real time are at increasing risk of falling behind before they even realize an attack has started.

Hackers are Increasingly Weaponizing Trusted Tools

The concept of “living off the land” refers to attackers using tools already present on a target’s system, such as PowerShell, Windows Script Host, or JavaScript environments, rather than deploying external malware.

This approach makes malicious activity blend with normal operations, drastically cutting detection chances.

The Q1 2026 report shows LOLBAS attacks using JavaScript grew by 58.4% during the quarter. Attackers exploit built-in scripting tools to execute malicious code without dropping a traditional malware file on disk.

This fileless approach is particularly effective against endpoint solutions that rely on file scanning rather than behavioral monitoring.

What makes this trend especially alarming is the speed at which these attacks unfold. When initial access is gained, persistence is established within seconds, leaving a razor-thin window for defenders to respond.

Credential abuse combined with native tool exploitation allows attackers to operate quietly for long periods without triggering any alerts.

Detection in this environment demands a new approach entirely. Behavior-based monitoring and anomaly investigation are now essential for any organization serious about security. Waiting for a known malicious file to appear is simply no longer a viable strategy.

The Rising Cost of Delayed Detection

Perhaps the most striking insight from the report is not the variety of attack techniques but how quickly they play out. Persistence can be established in just 21 seconds after initial compromise, exposing a serious gap in how most organizations approach threat detection today.

Loader-based attacks grew by 98.3%, nearly doubling in a single quarter. These tools operate in the earliest phases of an attack to download and execute additional malware on a compromised system.

Their rapid growth signals that threat actors are focused on securing a foothold first and escalating later. Identity remains a primary target, with credential theft rising by 14.7%.

Attackers armed with valid credentials can move through a network appearing as legitimate users, making it very hard to separate malicious behavior from normal activity. This is where behavioral analytics and rapid triage become critical.

The report recommends that security teams prioritize early-stage threat visibility and invest in real-time investigation capabilities.

Reducing investigation delays, confirming exposure faster, and strengthening detection coverage across all major platforms are the core priorities for Q2 2026. Organizations acting on these findings will be far better positioned to limit damage when the next wave arrives.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.

The post Hackers are Increasingly Weaponizing Trusted Tools to Deploy Notorious Malware appeared first on Cyber Security News.

Researchers have found a Magecart attack that uses Stripe, the widely used online payment service, as both its command center and its data dump.

Instead of pointing stolen card data to a shady server, attackers are routing everything through infrastructure that online stores already fully trust.

What makes this attack especially dangerous is how invisible it is to most security tools. The malware never loads from a domain the attacker owns.

Instead, both the payload and the stolen card data travel through api.stripe.com, a domain that virtually every e-commerce store allows by default. That means the traffic filters and security policies that would normally catch a skimmer simply let this one pass through.

Analysts at Sansec, a firm specializing in e-commerce security, identified this Magecart family and published their findings on June 4, 2026.

According to a Sansec report shared with Cyber Security News (CSN), Sansec said the attacker stores the card-stealing code inside a Stripe customer’s metadata, then runs it on checkout pages before writing stolen card numbers back into the same account disguised as fake customers. Stripe is being used as free criminal infrastructure.

The attack also relies on Google Tag Manager to deliver its initial loader. Real GTM containers, including one identified as GTM-P6KZMF63, were planted with a custom tag and served directly from googletagmanager.com.

This lets the loader blend in alongside a store’s legitimate analytics tags, making it much harder to detect without a careful manual audit.

The campaign appears to have been running since at least December 2025, based on the creation date of the Stripe account used in the attack.

The record was created on December 24, 2025, using what looks like a default template from Stripe’s own sample data, complete with a placeholder name and email address.

New Magecart Attack

The malware splits its work into three steps. First, the loader embedded inside a real GTM container fires on every page it loads.

When it detects a checkout page, it reaches out to a specific Stripe customer record controlled by the attacker and pulls down the skimmer code in chunks stored across multiple metadata fields.

Once downloaded, the skimmer attaches itself to the checkout button and waits. The moment a shopper clicks to complete a purchase, it captures the full card number, expiration date, CVV, billing address, and order total.

That data is then XOR-encoded and quietly stored in the browser’s local storage rather than being sent right away.

The actual theft happens on a delay. A separate routine checks for stored card data one second after each page load, and again every 60 seconds after that.

When it finds a record, it splits the data in half and posts it to Stripe’s customer API as a fake entry. The attacker can later retrieve all stolen cards by simply listing customers in their own Stripe account.

A Second Variant Using Google Firestore

Sansec also found a related variant that swaps Stripe for Google Firestore, Google’s cloud-hosted database service.

This version pulls its skimmer payload from a Firestore document inside a project named braintree-payment-app, a name chosen to look like normal payment traffic and avoid raising any flags.

Both variants follow the same core idea: abuse a mainstream, trusted cloud service as a hidden channel that no standard security rule would block.

The Firestore variant shows the attacker group is actively building out multiple delivery channels for their skimmer toolkit.

Sansec recommends that store owners audit all client-side scripts for any Stripe secret keys, since no legitimate front-end code ever carries one.

Any api.stripe.com or firestore.googleapis.com calls found in browser JavaScript should be treated as a sign of compromise. Store owners should also review every tag inside their Google Tag Manager account and remove anything they did not personally add.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.

The post New Magecart Attack Turns Stripe into a Malware Command Server appeared first on Cyber Security News.