Security & IT News

CVSSv3 Score: 5.2 A use of potentially Dangerous Function vulnerability [CWE-676] in FortiAnalyzer and FortiManager API may allow an authenticated attacker to cause a system hang via multiple specially crafted HTTP requests causing crashes. This happens if internal locks are aligned, which is out of control of the attacker. Revised on 2026-05-12 00:00:00

CVSSv3 Score: 2.1 A Missing Authorization [CWE-862] in FortiClient Windows may allow an authenticated local attacker to decrypt a currently logged in users VPN password via use of an unprotected DLL function. Revised on 2026-05-12 00:00:00

CVSSv3 Score: 9.1 An Improper Access Control vulnerability [CWE-284] in FortiAuthenticator may allow an unauthenticated attacker to execute unauthorized code or commands via crafted requests. Revised on 2026-05-12 00:00:00

CVSSv3 Score: 9.1 A missing authorization vulnerability [CWE-862] in FortiSandbox, FortiSandbox Cloud and FortiSandbox PaaS WEB UI may allow an unauthenticated attacker to execute unauthorized code or commands via HTTP requests. Revised on 2026-05-12 00:00:00

CVSSv3 Score: 8.3 An Out-Of-Bounds Write vulnerability [CWE-787] in FortiOS capwap daemon may allow an attacker controlling an authenticated FortiAP FortiExtender or FortiSwitch to gain execution privileges on the FortiGate device Revised on 2026-05-12 00:00:00

CVSSv3 Score: 5.1 An improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability [CWE-89] in FortiNDR may allow an authenticated attacker to execute arbitrary SQL commands on selected databases and tables via specifically crafted HTTP requests. Revised on 2026-05-12 00:00:00

Apple on Monday officially released iOS 26.5 with support for end-to-end encryption (E2EE) to Rich Communication Services (RCS) in beta as part of a "cross-industry effort" to replace traditional SMS with a more secure alternative. To that end, E2EE RCS messaging is rolling out to iPhone users running iOS 26.5 with supported carriers and Android users on the latest version of Google Messages.

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

California Attorney General Rob Bonta announced a proposed $12.75 million settlement agreement with General Motors (GM) over allegations that the company violated the California Consumer Privacy Act (CCPA). [...]

Checkmarx has confirmed that a modified version of the Jenkins AST plugin was published to the Jenkins Marketplace. "If you are using Checkmarx Jenkins AST plugin, you need to ensure that you are using the version 2.0.13-829.vc72453fa_1c16 that was published on December 17, 2025 or previously," the cybersecurity company said in a statement over the weekend. As of writing, Checkmarx has released

A threat actor named Mr_Rot13 has been attributed to the exploitation of a recently disclosed critical cPanel flaw to deploy a backdoor codenamed Filemanager on compromised environments. The attack exploits CVE-2026-41940, a vulnerability impacting cPanel and WebHost Manager (WHM) that could result in an authentication bypass and allow remote attackers to gain elevated control of the control

A few months ago, I implemented Cloudflare's Turnstile CAPTCHA on some pages. The reason for implementing these CAPTCHAs is obvious: Bots make up a large percentage of traffic and affect site performance. So I figured it was a good time to look back and see how effective these CAPTCHA are. The quick number: Out of about 300 requests, only 1 passed the test. Or 99.7% of requests came from bots. And this is after we have been running this for a few months. Some bots may have stopped scanning the page. But what about false positives? One false positive I noted from the login page was people clicking Submit on the login form before the CAPTCHA test was completed. This was easily fixed with a bit of JavaScript, which enabled the button only after a test was completed. Some of the top offenders: 219.117.237.208. - resolves to 219.117.237.208.static.zoot.jp and appears to be some kind of spider 18.229.88.75 - an AWS host, also attempting to download our IP data 164.52.120.0/24 - Cloud provider in HK 2a03:2880:f806::/48 - Facebook Ireland So far, I have received only a few complaints about false positives (aside from the now fixed login page issue). Why I selected Turnstile over other CAPTCHA options: Cloudflare's turnstile implementation appears to have fewer privacy issues than others, like Google Recaptcha They are in my opinion, low impact to the user Implementing them on the site wasn't too difficult We already use Cloudflare as a CDN. They work well enough CAPTCHA can often be bypassed. The right CAPTCHA solution makes it hard enough for an attacker to bypass that the value of the data they would be getting is not worth the effort. -- Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu Twitter | (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

The Rapid7 2026 Global Cybersecurity Summit is just around the corner, and with it, a final opportunity to join the conversations shaping how security teams are adapting to a rapidly changing landscape. Over the past few weeks, we’ve shared a preview of what to expect, from the sessions and speakers to the themes running across the agenda. What has become increasingly clear is how closely these topics are connected. Security teams are being asked to move beyond reacting to incidents and instead understand how attacks begin, how they evolve, and how decisions can be made earlier with greater confidence. What you will gain from attending Across two days, the summit is structured to reflect how security teams actually operate. The first day builds a shared understanding of how the threat landscape has shifted, while the second day offers more focused sessions tailored to both leaders and practitioners. Sessions such as The Reality of Running a SOC in 2026 and Inside the Modern SOC explore how attacks unfold in practice, following signals from initial access through to response. These discussions highlight how analysts interpret activity across identity, cloud, and endpoint environments, and how decisions are made when multiple signals compete for attention. Other sessions, including Beyond the Vulnerability List and From Cloud Exposure to Runtime Attack , focus on how exposure is changing the way teams prioritize risk. The emphasis is on understanding context and how exposed assets actually are to attackers, helping teams determine which issues are most likely to lead to impact and where effort should be focused. Alongside this, sessions like The AI Dilemma: Automating Defense Without Surrendering Judgment examine how AI is being applied within SOC workflows. The discussion moves beyond theory and looks at how teams are balancing automation with human oversight, ensuring that speed does not come at the expense of trust or accountability. What’s changing for security teams right now Security operations are evolving in response to changes in both attacker behavior and organizational complexity. Environments are more distributed, signals are more fragmented, and the time available to respond continues to shrink. As a result, the focus is shifting toward earlier action, better prioritization, and more connected decision-making. This means linking exposure with detection, reducing unnecessary noise, and building workflows that allow teams to act with clarity when it matters most. Across the summit, these ideas are explored from multiple perspectives, but they consistently point toward the same outcome. Teams that can connect context, visibility, and response are better positioned to reduce risk before it becomes an incident. Secure your place With the event approaching, this is the final opportunity to register and take part in these discussions. Whether you are responsible for strategy, operations, or day-to-day detection and response, the summit is des

Rough Monday. Somebody poisoned a trusted download again, somebody else turned cloud servers into public housing, and a few crews are still getting into boxes with bugs that should’ve died years ago — the same old holes, same lazy access paths, same “how the hell is this still open” feeling. One report this week basically reads like a guy tripped over root access by accident and decided to stay

Defending a network at 2 am looks a lot like this: an analyst copy-pasting a hash from a PDF into a SIEM query. A red team script is being rewritten by hand so the blue team can use it. A patch waiting on a change-approval window that's longer than the exploitation window itself. Nobody in that chain is incompetent. Every human is doing their job correctly. The problem is the system, its

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

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

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

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