Security & IT News

Hackers are abusing Vercel GenAI to create convincing phishing sites that mimic major brands, including Microsoft, Adidas, and Nike, making scams harder to detect.

ShinyHunters has escalated its Canvas extortion campaign, defacing hundreds of school login pages and threatening to leak stolen data unless institutions negotiate

ShinyHunters gets away with emails and other data on 200,000 Zara customers

Spanish police have arrested the suspected administrator of German dark web marketplace Crimenetwork

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

YARA-X's 1.16.0 release brings 4 improvements and 4 bugfixes. Didier Stevens Senior handler blog.DidierStevens.com (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Evidence of them has been found by analyzing DNA in the seawater. As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered. Blog moderation policy.

Spring cleanup This week’s Metasploit updates focused on foundational improvements and expanded target reach. Key enhancements were made to the recently released Copy Fail exploit module, which now benefits from payload fixes in linux/x64/exec and linux/armle/exec. These changes expand its capability, enabling the use of the cmd/unix/python/meterpreter/reverse_tcp payload on x64 targets and introducing support for ARMLE Linux. Additionally, the exploit/multi/http/shiro_rememberme_v124_deserialize module has been improved to allow operators to adjust the deserialization chain, enabling exploitation of a broader set of targets. Finally, several critical utility modules, including the FTP anonymous scanner and other FTP modules, received general fixes and updates. New module content (1) Anonymous FTP Access Detection Authors: Matteo Cantoni [email protected] and g0tmi1k Type: Auxiliary Pull request: #21372 contributed by g0tmi1k Path: scanner/ftp/ftp_anonymous AttackerKB reference: CVE-1999-0497 Description: This updates the FTP anonymous scanner module. Key changes include moving the module to align with other generic FTP modules, adding and updating CVE references and documentation notes, and cleaning up the output to be more verbose. Additionally, the module now reports service and vulnerability data to the database and stores proof-of-exploitation info in the loot upon a successful run. Enhanced Modules (2) Modules which have either been enhanced, or renamed: #21410 from inkognitobo - This improves the exploit/multi/http/shiro_rememberme_v124_deserialize module by adding a JAVA_GADGET_CHAIN datastore option that allows the operator to adjust the chain used for deserialization. This enables the module to exploit additional targets. #21404 from zeroSteiner - This extends the support of Copy Fail to ARMLE Linux targets. Enhancements and features (4) #21342 from adfoster-r7 - Defers the loading of some dependencies to improve console boot time. #21372 from g0tmi1k - This updates the FTP anonymous scanner module. Key changes include moving the module to align with other generic FTP modules, adding and updating CVE references and documentation notes, and cleaning up the output to be more verbose. Additionally, the module now reports service and vulnerability data to the database and stores proof-of-exploitation info in the loot upon a successful run. #21380 from g0tmi1k - Updates multiple FTP modules to now register FTP service information in the database when successfully connecting to an FTP service. #21418 from kx7m2qd - This improves the platform-agnostic library used to obtain the OS architecture with support for shell sessions on Linux, BSD and Mac OSX. Bugs fixed (5) #21314 from g0tmi1k - Fixes a crash when running the scanner/http/trace module with the database enabled and a vulnerability was reported. #21411 from zeroSteiner - This fixes a bug in the linux/x64/exec payload that was caused by the CMD datastore option being placed in the assemb

Insider trading is rife on Polymarket: Analysis by the Anti-Corruption Data Collective, a non-profit research and advocacy group, found that long-shot bets—­defined as wagers of $2,500 or more at odds of 35 percent or less—­on the platform had an average win rate of around 52 percent in markets on military and defense actions. That compares with a win rate of 25 percent across all politics-focused markets and just 14 percent for all markets on the platform as a whole. It is absolutely insane that this is legal. We already know how insider betting warps sports. Insider betting warping politics—and military actions—is orders of magnitude worse.

A report by Poland’s top intelligence agency accused Russia of sabotage and hacking activities against the country’s military and civilian infrastructure.

In this article Why Dirty Frag matters Technical overview Exploitation scenarios Mitigation guidance Post-mitigation integrity verification References A newly disclosed Linux local privilege escalation vulnerability known as “Dirty Frag” enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500). Public reporting and proof-of-concept activity indicate the exploit is designed to provide more reliable privilege escalation than traditional race-condition-dependent Linux local privilege escalation techniques. Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account. Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft Defender is actively monitoring related activity and investigating additional detections and protections. This article details an ongoing investigation into active campaign. We will update this report as new details emerge. Why Dirty Frag matters Local privilege escalation vulnerabilities are frequently used by threat actors after initial access to expand control over a compromised environment. Once root access is obtained, attackers can disable security tooling, access sensitive credentials, tamper with logs, pivot laterally, and establish persistent access. Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability. Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments. This increases operational risk in environments where threat actors already possess limited local execution capability through compromised accounts, vulnerable applications, containers, or exposed administrative interfaces. Technical overview Dirty Frag abuses Linux kernel networking and memory-fragment handling behavior involving esp4, esp6, and rxrpc components. Similar to the previously disclosed CopyFail vulnerability (CVE-2026-31431), the exploit attempts to manipulate Linux page cache behavior to achieve privilege escalation. However, Dirty Frag introduces additional attack paths that expand exploitation opportunities and improve reliability. The vulnerability affects systems where vulnerable modules are present and accessible. In many enterprise environments, these components may already be enabled to support IPsec, VPN functionality, or other networking workloads. Exploitation scenarios Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including: Compromised SSH accounts Web-shell access on internet-facing applications Cont

Former cybersecurity executive Peter Williams stole several surveillance and hacking tools and sold them for $1.3 million to a Russian broker that works with Putin’s government.

Every engineering team in your organization ships code through a pipeline. They branch, test, review, and deploy. If something breaks, they roll back. If someone asks "what changed?", the answer is in the commit history. This isn't heroic discipline to process; it's just how software gets built. Now think about how your detection engineering team works. Rules get written in a UI. Maybe copied and pasted from a wiki. There's no peer review; someone clicks "save," and it's live. No test cases validate the logic before deployment. No rollback if something breaks. When an alert suddenly floods your SOC, good luck figuring out what changed and when. When a detection stops firing, you might not notice for weeks. This is, by definition, a process gap . And it's one that the rest of engineering solved years ago. The gap becomes manageable through the five custom rules, listed below. As your detections grow, you need the same discipline that every other engineering team already has. Process Stage How it works in software engineering How it works in detection engineering Storage Git / Version Control UI / Wiki / "Tribal Knowledge" Validation Automated CI/CD Tests "Wait and see if it fires" Review Peer-reviewed Pull Requests Single-user "Save" button Rollback One-click git revert Manual query deletion How does this help my security team? Detection as Code gives your team a structured, repeatable way to build and manage detections with confidence. Instead of relying on manual updates and guesswork, every change is tested, reviewed, and tracked before it reaches production. Before we get into the how , here's why Detection as Code changes the way your team works: A more reliable process. Every change goes through version control and peer review before it goes live. When something goes wrong, you know exactly what changed, when it changed, and who approved it. Roll back in seconds if needed. A safety net of tests. Inline test cases validate detection logic before deployment. Positive tests prove it catches the threat; negative tests prove it doesn't fire on legitimate activity. Confidence in what's deployed. terraform plan previews every change before anything touches production. Terraform state is the authoritative record of your detection estate, not some spreadsheet. The result is a detection workflow your team can trust. Changes are predictable, validated, and fully traceable, so security teams don’t get caught up in troubleshooting and can focus on improving coverage and overall posture. The anatomy of a detection Here is what a detection rule looks like using Rapid7’s Terraform provider . It offers a practical view of how detection engineering teams can use Detection as Code in practice: resource "rapid7_siem_detection_rule" "encoded_powershell" { name = "Encoded PowerShell Command Execution" description = "Detects PowerShell launched with base64-encoded commands" techniques = ["T1059.001"] action = "CREATES_ALERTS" priority = "HIGH" logic = { leql = -LE

p CISA has added nbsp;one nbsp;new vulnerability nbsp;to its nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" Known Exploited Vulnerabilities (KEV) Catalog /a , based on evidence of active exploitation. /p ul type="disc" li a href="https://www.cve.org/CVERecord?id=CVE-2026-42208" target="_blank" CVE-2026-42208 /a nbsp;BerriAI nbsp;LiteLLM nbsp;SQL Injection Vulnerability /li /ul p This nbsp;type nbsp;of vulnerability is a nbsp;frequent attack vector nbsp;for malicious cyber actors and poses nbsp;significant risks to the federal enterprise. /p p a href="https://www.cisa.gov/binding-operational-directive-22-01" Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities /a nbsp;established the KEV Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the nbsp; a href="https://www.cisa.gov/sites/default/files/publications/Reducing_the_Significant_Risk_of_Known_Exploited_Vulnerabilities_211103.pdf" BOD 22-01 Fact Sheet /a nbsp;for more information. /p p Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing nbsp;timely nbsp;remediation of nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" KEV Catalog vulnerabilities /a nbsp;as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities" specified criteria /a . nbsp; /p

An ongoing data extortion attack targeting the widely-used education technology platform Canvas disrupted classes and coursework at school districts and universities across the United States today, after a cybercrime group defaced the service’s login page with a ransom demand that threatened to leak data from 275 million students and faculty across nearly 9,000 educational institutions. A screenshot shared by a reader showing the extortion message that was shown on the Canvas login page today. Canvas parent firm Instructure responded to today’s defacement attacks by disabling the platform, which is used by thousands of schools, universities and businesses to manage coursework and assignments, and to communicate with students. Instructure acknowledged a data breach earlier this week, after the cybercrime group ShinyHunters claimed responsibility and said they would leak data on tens of millions of students and faculty unless paid a ransom. The stated deadline for payment was initially set at May 6, but it was later pushed back to May 12. In a statement on May 6, Instructure said the investigation so far shows the stolen information includes “certain identifying information of users at affected institutions, such as names, email addresses, and student ID numbers, as well as as messages among users.” The company said it found no evidence the breached data included more sensitive information, such as passwords, dates of birth, government identifiers or financial information. The May 6 update stated that Canvas was fully operational, and that Instructure was not seeing any ongoing unauthorized activity on their platform. “At this stage, we believe the incident has been contained,” Instructure wrote. However, by mid-day on Thursday, May 7, students and faculty at dozens of schools and universities were flooding social media sites with comments saying that a ransom demand from ShinyHunters had replaced the usual Canvas login page. Instructure responded by pulling Canvas offline and replacing the portal with the message, “Canvas is currently undergoing scheduled maintenance. Check back soon.” “We anticipate being up soon, and will provide updates as soon as possible,” reads the current message on Instructure’s status page . While the data stolen by ShinyHunters may or may not contain particularly sensitive information (ShinyHunters claims it includes several billion private messages among students and teachers, as well as names, phone numbers and email addresses), this attack could hardly have come at a worse time for Instructure: Many of the affected schools and universities are in the middle of final exams, and a prolonged outage could be highly damaging for the company. The extortion message that greeted countless Canvas users today advised the affected schools to negotiate their own ransom payments to prevent the publication of their data — regardless of whether Instructure decid

The cybercrime group ShinyHunters claimed to have hacked Instructure again, defacing the login pages of several Instructure customer schools with an extortion message.

In this article A representative case study: Semantic Kernel CVE-2026-26030: In-Memory Vector Store CVE-2026-25592: Arbitrary file write through SessionsPythonPlugin The vulnerability Attack chain overview Defending the agentic edge Not bugs, but developed by design CTF challenge: Attack your own agent Learn more AI agents have fundamentally changed the threat model of AI model-based applications. By equipping these models with plugins (also called tools), your agents no longer just generate text; they now read files, search connected databases, run scripts, and perform other tasks to actively operate on your network. Because of this, vulnerabilities in the AI layer are no longer just a content issue and are an execution risk. If an attacker can control the parameters passed into these plugins via prompt injection, the agent may be driven to perform actions beyond its intended use. The AI model itself isn’t the issue as it’s behaving exactly as designed by parsing language into tool schemas. The vulnerability lies in how the framework and tools trust the parsed data. To build powerful applications, developers rely heavily on frameworks like Semantic Kernel, LangChain, and CrewAI. These frameworks act as the operating system for AI agents, abstracting away complex model orchestration. But this convenience comes with a hidden cost: because these frameworks act as a ubiquitous foundational layer, a single vulnerability in how they map AI model outputs to system tools carries systemic risk. As part of our mission to make AI systems more secure and eliminate new class of vulnerabilities, we’re launching a research series focused on identifying vulnerabilities in popular AI agent frameworks. Through responsible disclosure, we work with maintainers to ensure issues are addressed before sharing our findings with the community. In this post, we share details on the vulnerabilities we discovered in Microsoft’s Semantic Kernel, along with the steps we took to address them and interactive way to try it yourself. Stay tuned for upcoming blogs where we’ll dive into similar vulnerabilities found in frameworks beyond the Microsoft ecosystem. Background We discovered a vulnerable path in Microsoft Semantic Kernel that could turn prompt injection into host-level remote code execution (RCE). A single prompt was enough to launch calc.exe on the device running our AI agent, with no browser exploit, malicious attachment, or memory corruption bug needed. The agent simply did what it was designed to do: interpret natural language, choose a tool, and pass parameters into code. Figure 1. Illustration of CVE-2026-26030 exploitation using a local model. This scenario is the real security story behind modern AI agents. Once an AI model is wired to tools, prompt injection draws a thin line between being just a content security problem and becoming a code execution primitive. In this post in our research series on AI agent framework security, we show how two vulnerabilities in

Wade Woolwine is Senior Director, Product Security at Rapid7. Announcing OpenAI's Trusted Access for Cyber program CIOs and CISOs are telling us the same thing in different ways: Advances in frontier AI are accelerating the threat environment and putting pressure on security operating models built for a different pace. Vulnerabilities can be discovered faster, exploitation windows are shrinking, and attackers are increasingly using automation to move with greater speed and scale. For defenders, this changes the value equation. The premium is no longer only on detecting threats faster after they emerge, but on moving earlier: Reducing exposure, validating risk, strengthening detection, and remediating at scale before attackers can take advantage. This is why Rapid7 is excited to be included in OpenAI’s Trusted Access for Cyber program and their announcement today. OpenAI’s approach recognizes that advanced AI can help verified security teams move faster on legitimate defensive work, from triage and detection to validation, patching, malware analysis, and detection engineering. It also recognizes that some specialized cyber workflows require stronger verification, monitoring, and feedback loops. As Corey Thomas, CEO of Rapid7, shared: “Security leaders are under pressure from every direction: More vulnerabilities, faster exploitation, and increasing business pressure. Through OpenAI’s Trusted Access for Cyber program, Rapid7 is exploring more ways to accelerate the shift from reactive to preemptive security. To stay ahead of attackers, defenders must proactively reduce exploitability and detect with machine-scale speed and precision. We’re working with OpenAI to equip security teams with advanced capabilities that will meaningfully improve their cyber resilience.” AI in security: Not just faster discovery For Rapid7, this moment is about more than faster vulnerability discovery. AI is creating new pressure across the entire security lifecycle, from vulnerability validation, prioritization, disclosure, and remediation to threat and exploitation detection. Security infrastructure built for human-speed discovery now needs to operate in a machine-speed world, with enough context, governance, and accountability to help defenders act with confidence. Finding risk is only the beginning. Security teams need to understand which vulnerabilities and misconfigurations are truly exploitable, which systems and business services are affected, what compensating controls are in place, how remediation should be prioritized, and where detection coverage is needed. CISOs also need confidence that advanced AI is being applied responsibly, with clear guardrails, measurable outcomes, and accountability. Our work with OpenAI will help us explore how frontier AI can strengthen three critical areas. First, it can support the identification of vulnerabilities in our own products and code earlier in the development lifecycle. By accelerating secure code review, surfacing risk

An unknown group of hackers is breaking into systems previously breached by the cybercrime group TeamPCP. Once inside, the hackers immediately kick out TeamPCP and remove its hacking tools from the victims’ systems.

Security researchers at Mozilla say Anthropic's Mythos has unearthed a wealth of high-severity bugs in Firefox.