Trending Topics

ASP NET Core Critical Vulnerability: When Request Smuggling Becomes a Security Feature Bypass

Microsoft has patched a maximum-severity vulnerability in ASP[.]NET Core, tracked as CVE-2025-55315, that allows HTTP request smuggling via the built-in Kestrel web server. With a CVSS score of 9.9 out of 10, the flaw is serious enough that Microsoft classifies it as a security feature bypass that changes scope - allowing a lower-privileged request to effectively masquerade as a higher-privileged one.

The bug arises from inconsistent interpretation of HTTP requests between Kestrel and upstream components, particularly when headers like Content-Length and Transfer-Encoding are involved. This inconsistency allows an attacker to smuggle a second request inside the first. A public unauthenticated request can carry a hidden GET /admin request that slips past normal authentication and authorization checks if the application and any proxies in front of it do not consistently enforce request boundaries.

The issue affects ASP[.]NET Core and .NET Core 8.0, 9.0, and 10.0, as well as the Kestrel package on 2.x. Microsoft notes there are no general mitigating factors beyond patching. Depending on how an application processes requests, unpatched systems may be open to privilege escalation, server-side request forgery, cross-site request forgery bypass, and input validation bypass - all stemming from poisoned assumptions about which user or session a given request belongs to.

One additional wrinkle: Microsoft does not issue CVEs for end-of-life releases, so .NET 6 does not appear in the advisory. Analysis indicates that .NET 6-based applications using affected Kestrel builds remain vulnerable and require third-party or package-level fixes to address the issue.

To remediate, Microsoft urges developers to update to the patched ASP.NET Core and .NET Core runtime and SDK versions 8, 9, or 10, or at minimum to upgrade Microsoft.AspNetCore.Server.Kestrel.Core to version 2.3.6 or later, then redeploy their applications. Teams should also review and harden any reverse proxies or load balancers in front of Kestrel, ensuring they normalize HTTP requests and detect smuggling attempts rather than passing ambiguous traffic through.

Security engineers should pay particular attention to code that uses HttpRequest.Body, HttpRequest.BodyReader, or similar mechanisms, as these are the points where smuggled data may be processed in unexpected ways. Microsoft and community researchers have released test tools and sample applications that reproduce chunked transfer and newline parsing edge cases, so teams can verify whether their builds and configurations are affected and confirm that defenses hold after patching.

Self-Spreading npm Attack: Malicious Packages Steal GitHub Tokens and Rewrite Your Own Projects

A newly reported npm supply chain campaign is abusing malicious JavaScript packages that steal GitHub and CI/CD authentication tokens and then self-propagate by silently injecting themselves into other projects and repositories the victim works on. The packages present as normal utilities or helpers. Once installed, they execute code during npm lifecycle hooks - preinstall or postinstall - fetch a remote payload, and begin harvesting secrets and modifying local repositories without any further action from the developer.

The malware performs extensive environment reconnaissance, searching for GitHub access tokens, npm tokens, CI/CD variables, and other authentication secrets stored in files, environment variables, or config directories. Stolen credentials are exfiltrated to attacker-controlled servers over HTTP POST or WebSocket connections. With those tokens, the actors can clone private repositories, create new branches, and push malicious changes or workflows back to GitHub - turning the victim's own projects into new infection vectors for teammates, customers, and downstream users.

Some campaign variants go further, injecting additional malicious dependencies into package.json so that other developers who run npm install automatically pull in and execute the same payload. That is why researchers describe this as self-spreading: each new victim becomes a distribution point.

For developers and teams, the response involves both dependency hygiene and credential discipline. Pin dependencies, use tools that scan for known malicious packages and suspicious install scripts, and review package.json and package-lock.json diffs carefully - especially in pull requests where new dependencies can slip through unnoticed. On the credential side, move to short-lived, scoped tokens, avoid storing tokens unencrypted on developer machines, and monitor for unusual GitHub activity such as unexpected new branches, commits from unfamiliar IPs, or changes to workflow files.

If you suspect exposure, revoke GitHub and npm tokens immediately, rotate CI/CD secrets, and audit repositories for unauthorized code or workflow modifications. The real damage here is not just local compromise - it's the silent corruption of the software you ship to others.

Bluesky Back Online After DDoS Barrage, as Pro-Iran “313 Team” Claims the Hit

Bluesky, the decentralized social network positioned as an alternative to Twitter/X, spent roughly a day dealing with outages after a DDoS attack knocked core features offline. The disruption began late on April 15, 2026, when users saw feeds stop refreshing around 11:40PM PDT. By the following morning, notifications, search, and thread loading were all failing, leaving the platform effectively unusable for many users.

Bluesky later confirmed that its API, which ferries data between user devices and the backend, was being flooded with junk traffic to “jam the lines”, describing the incident as a “sophisticated DDoS attack” while emphasizing there was no evidence of unauthorized access to private user data. By April 20, the company reported that the app had returned to a stable state after its security team contained repeated attempts by attackers to relaunch the flood.

Bluesky stopped short of naming a culprit, but a pro-Iran hacktivist group known as 313 Team - also called the Islamic Cyber Resistance in Iraq - quickly claimed responsibility on Telegram and other channels. The group has a recent history of politically motivated DDoS and website disruption campaigns against targets it associates with the United States, Israel, and allied states. Days after the Bluesky incident, it announced a follow-up hit on mastodon.social, which saw more limited impact thanks to that platform's federated, distributed hosting model.

Analysts note that 313 Team tends to chase visibility rather than deep intrusion, favoring short burst outages, screenshots, and claims of disruption over data theft. The group recently used similar tactics against government services in Bahrain.

For Bluesky's more than 43 million users, the key reassurance is that this attack was about availability, not data compromise. DDoS operations work by overwhelming public-facing services with traffic - not by breaking into databases - and Bluesky has reiterated that its monitoring found no signs of private data exposure.

The incident does illustrate how social platforms and high-profile public services have become regular fixtures in geopolitical cyber signaling. Groups like 313 Team can generate headlines and amplify narratives simply by knocking popular apps offline for a few hours. For defenders running similar platforms or APIs, that trend reinforces the need for robust DDoS mitigation, scalable API protection, and clear public communication plans - so that when traffic floods arrive, teams can keep services running and quickly reassure users about what was and was not affected.

Sinobi Ransomware: Exclusive RaaS Group With Nation State Style Tradecraft

Sinobi is a hybrid, semi-private ransomware-as-a-service operation that emerged in mid-2025 and has quickly built a reputation for quiet, high-impact intrusions against midsize and large organizations, primarily in the United States and allied countries. Rather than opening sign-ups on underground forums, the core operators work exclusively with vetted, well-connected affiliates - many of whom already have access routes through initial access brokers, compromised managed service providers, or existing VPN and firewall exploits such as SonicWall SSL VPN vulnerabilities.

Technically, Sinobi appears to be a direct successor or rebrand of the Lynx ransomware group, itself linked to earlier INC ransomware. It uses a Babuk-derived cryptographic scheme combining Curve25519 key exchange with AES-128 CTR, which makes recovery without the attackers' private key practically impossible.

Once inside a victim network, Sinobi runs a hands-on keyboard attack chain that resembles high-end intrusion sets more than commodity ransomware. Affiliates begin with privilege escalation and security evasion - creating or hijacking local admin and domain accounts, disabling endpoint protection and logging, and establishing persistence through legitimate remote access tools. They then conduct automated and manual reconnaissance to map domains, file shares, privileged accounts, endpoint security products, and in some cases USB devices, suggesting at least some interest in removable media-based propagation. Lateral movement relies heavily on RDP, SMB, and DCOM using valid or newly created credentials alongside extensive living-off-the-land activity, which helps Sinobi blend into normal administrative traffic and delay detection until the environment is fully staged for impact.

Like most modern big-game operations, Sinobi uses double extortion - exfiltrating data before encrypting systems. Affiliates typically deploy tools such as Rclone, WinSCP, or other secure file transfer clients to move large volumes of documents, databases, email archives, backups, and regulated records to attacker-controlled cloud storage or Tor infrastructure, prioritizing material that increases leverage such as customer data and intellectual property. Only after exfiltration do they execute the encryptor, usually during off hours, appending a ".SINOBI"-style extension, deleting shadow copies and backups, terminating critical services, changing desktop wallpapers, and dropping a ransom note with a Tor negotiation portal and a short payment deadline.

Public casework and leak site data suggest Sinobi has already impacted dozens of organizations across accounting, manufacturing, and professional services, and that the group favors fewer, higher-value intrusions over mass opportunistic campaigns.

Sinobi is a reminder that professionalized RaaS crews now operate at maturity levels that resemble advanced intrusion groups, not smash-and-grab criminals. Effective mitigation starts with hardening remote access and third-party relationships: strict patching and monitoring of VPNs and edge appliances, phishing-resistant MFA, and close scrutiny of MSP and vendor connectivity since those pathways have already been abused in documented cases. Inside the network, prioritize credential hygiene and segmentation, restrict and monitor RDP and SMB traffic, and deploy EDR and logging tuned to detect living-off-the-land behavior, new admin account creation, Rclone or WinSCP activity, and unusual data egress to cloud storage.

Finally, ensure your backup and recovery processes are tested, isolated from domain credentials, and capable of surviving shadow copy deletion. When a group like Sinobi gets in, you want to negotiate from a position of resilience - not desperation.

Update: Over 1,300 SharePoint Servers Still Exposed to an Actively Exploited Spoofing Zero Day

More than 1,300 internet-exposed Microsoft SharePoint servers remain unpatched for CVE-2026-32201, a spoofing vulnerability that Microsoft has confirmed was exploited as a zero-day and is still being abused in active attacks. The flaw affects SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition, stemming from improper input validation that allows an unauthenticated attacker to perform network-level spoofing in low-complexity attacks requiring no user interaction.

Successful exploitation allows an unprivileged attacker to view sensitive information and modify disclosed data, undermining the confidentiality and integrity of SharePoint content and workflows. Availability is not directly affected, but that is a narrow comfort given the access an attacker can establish.

Microsoft patched CVE-2026-32201 in the April 2026 Patch Tuesday release and immediately labeled it a zero-day, though it has not yet shared technical exploit details or attributed the activity to a specific threat group. CISA added the bug to its Known Exploited Vulnerabilities catalog the same day and ordered U.S. Federal Civilian Executive Branch agencies to patch all affected SharePoint servers within two weeks, by April 28, under Binding Operational Directive 22-01. Despite that, data from the Shadowserver Foundation shows fewer than 200 servers have been updated since the patches dropped, leaving the majority of known exposed instances sitting on the public internet as a stable, well-understood target set.

For organizations running on-premises SharePoint, the path forward is clear. Identify all externally reachable SharePoint 2016, 2019, and Subscription Edition servers, apply the April 2026 security updates containing the CVE-2026-32201 fix, and where possible remove SharePoint from direct internet exposure by placing it behind a VPN or reverse proxy. Security teams should monitor for suspicious SharePoint traffic and access patterns, cross-check their environment against the CISA KEV listing, and confirm that any third-party-managed SharePoint instances have been patched.

Given SharePoint's history of vulnerabilities being chained together for code execution and key theft, leaving CVE-2026-32201 unpatched is not just a spoofing risk on a single site. It is a foothold that can be combined with other flaws to compromise broader Microsoft 365-integrated environments.