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.

Hola Browser for Windows, used by millions of users around the world, was found distributing an unexpected executable file alongside its legitimate installer.

The file, named me.exe, was not part of the browser’s declared software package, and it appears to have been silently dropped onto users’ systems without their knowledge or consent.

The issue came to light during a routine certification review conducted through the AppEsteem Windows Certified Application program.

AppEsteem, an AMTSO-certified organization founded in 2016, runs periodic validation tests to confirm that certified software matches its declared and approved installation footprint.

During one such test involving Hola Browser version 1.251.91.0, the unexpected file was detected sitting inside the browser’s installation directory at C:\Program Files\Hola\me.exe.

Analysts at Sophos X-Ops identified the suspicious file and flagged it as a Potentially Unwanted Application during the certification test.

According to Sophos report shared with Cyber Security News (CSN), Sophos noted that the binary was not code signed, carried no timestamp, contained obfuscated code, and had memory-write capability.

While each of these traits alone might not raise an alarm on its own, together they painted a clear picture of something that had absolutely no business being bundled with a certified application.

Further investigation revealed that the file did not appear in every single test run, which ruled out the possibility of it being hardcoded into the installer itself.

This inconsistency pointed instead to a delivery-path issue, suggesting that the binary was being pushed through the update distribution pipeline under specific conditions.

In short, AppEsteem had certified one clean version of Hola Browser, but some users were receiving more than what had been certified.

After the issue was escalated through AppEsteem to Hola, the company confirmed that me.exe was never meant to be part of their installer.

Hola’s CEO Avi Raz Cohen acknowledged that their internal monitoring had also detected the anomaly, and independent cybersecurity firm Sygnia was brought in to conduct a thorough forensic review.

Sygnia’s findings confirmed this was a supply chain compromise, with the incident affecting roughly 0.1% of users and no user data accessed or exfiltrated at any point.

Hola Browser for Windows Delivery Pipeline Compromised

The me.exe binary appears to be based on XMRig, a well-known open-source crypto-mining tool. When run with administrative rights, the file copies itself to a new path within the Hola directory and registers itself as a Windows service named hola_monitor_svc.

This service is set to autostart and activates specifically when the host machine is idle, making it harder for the average user to notice any unusual activity or performance slowdown.

To avoid detection, the binary also performed a Windows Defender exclusion, effectively asking the operating system to ignore its presence entirely.

The strings found inside the file, including references to stopping the miner when a user becomes active, suggest it was carefully designed to run quietly in the background at all times. Sophos has classified this particular threat under the detection name Troj/GoMiner-B.

Supply Chain Risk and Pipeline Integrity

This incident is a strong reminder that even certified and trusted software can become a vehicle for malicious payloads when the delivery pipeline itself is compromised.

The fact that the file did not appear consistently across test environments made it harder to catch through standard certification checks alone.

It took a combination of third-party testing and security vendor telemetry working together to ultimately surface the full scope of the issue.

Following the discovery, Hola rebuilt its distribution pipeline from the ground up, introduced advanced code-signing verification, and tightened access controls across its entire infrastructure.

The company also committed to continuous monitoring to ensure that only declared and properly signed components ever reach end users going forward.

The outcome here represents the certification ecosystem working as intended, with an integrity problem caught, escalated, and fully resolved before it could grow into something far more damaging.

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 Hola Browser for Windows Delivery Pipeline Compromised to Deliver Cryptominer appeared first on Cyber Security News.

The malware exploits a stack buffer overflow flaw in the UPnP service of affected routers, letting attackers gain full access without any credentials. Once inside, it works to actively recruit the compromised device into a rapidly growing botnet network.

What sets C0XMO apart from earlier Gafgyt versions is its modular design and ability to target multiple Linux processor architectures at once.

Attackers built the malware to compile and deliver architecture-specific payloads, giving it a broader reach than most IoT-targeting threats seen before. It also includes Python-based scanning scripts that help it move laterally across networks and locate new targets automatically.

Analysts from Fortinet’s FortiGuard Labs identified and analyzed the C0XMO variant, with a report shared with Cyber Security News (CSN).

According to FortiGuard Labs, the malware was first discovered in March and has since been observed actively exploiting CVE-2021-27137, a stack buffer overflow in the UPnP service of certain DD-WRT router firmware.

The flaw is triggered when an oversized ST:uuid value is sent in a crafted M-SEARCH request over UDP port 1900.

The broader impact of C0XMO is still being assessed, but the threat is significant given how widely DD-WRT firmware is deployed across home offices and small businesses worldwide.

Attackers are not only targeting routers — the malware also attempts to exploit exposed Android Debug Bridge connections to take over Android devices. This cross-platform approach signals growing sophistication among IoT botnet operators.

Beyond its primary attack path, C0XMO can launch distributed denial-of-service attacks once a device is recruited.

It also leverages CVEs targeting D-Link devices, GLPI project software, and Avtech DVR cameras, widening the attack surface considerably. Security teams managing mixed device environments should treat this threat as active and ongoing.

New Gafgyt Variant Targets Multiple Linux Architectures

One of the most technically notable aspects of C0XMO is how it separates lateral movement into a standalone Python script.

This design lets the botnet scan and probe networks independently of the main malware body, making it more flexible and harder to detect. The script identifies reachable hosts and determines the target’s architecture before delivering the appropriate payload.

The malware targets a range of Linux architectures including ARM, MIPS, and x86, covering routers, IoT sensors, and embedded devices broadly.

For each type, it downloads and executes the correct compiled binary, letting the botnet grow across different hardware in a single campaign.

This modular, multi-architecture design was previously more common among advanced threat actors, and its presence in an IoT botnet marks a clear escalation.

Fortinet researchers also observed the malware connecting to a command-and-control server after infection, waiting for DDoS commands and expansion orders.

The scanning modules run continuously in the background, identifying new devices and forwarding details to operators. Brute-force authentication attempts against reachable services were also noted as part of its traversal routine.

Exploitation of Known CVEs and Defensive Recommendations

C0XMO’s success depends on known, unpatched vulnerabilities that have had available fixes for some time. CVE-2021-27137 in DD-WRT, CVE-2015-2051 in D-Link devices, CVE-2022-35914 in GLPI project software, and multiple Avtech DVR camera flaws are all part of its exploit toolkit.

The persistence of these flaws reflects how slowly patching tends to happen across the IoT space. Users running affected devices should prioritize firmware updates right away.

Disabling UPnP on DD-WRT routers where it is not needed eliminates the primary entry point C0XMO relies on. Blocking external access to UDP port 1900 with firewall rules can also reduce exposure considerably.

Monitoring network traffic is equally important for catching infections early. Unusual outbound connections, unexpected UDP traffic spikes on port 1900, and brute-force login attempts are all signs of possible compromise.

Security teams should focus attention on older and unmanaged IoT devices, which often remain unpatched and make ideal targets for campaigns like this one.

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 Gafgyt Variant Targets Multiple Linux Architectures With Modular Propagation appeared first on Cyber Security News.