Cybersecurity Meets AI: Key Takeaways from CyberML
Summary Cybersecurity and AI are two of the fastest-moving areas in tech, so a conference dedicated to their intersection felt both timely and necessary. CyberML covered a wide range of topics: AI-assisted hacking, AI security evaluation, agent-based pentesting, blue-team automation, vulnerability prioritization, RAG poisoning, MCP security, identity for agents, deepfakes, fraud, and more. The talks were different in style: some technical, some product-focused, and some strategic. But together they delivered one clear message: AI is already changing almost every part of the security practitioner’s work. This article summarizes the main insights I took from the conference, with a focus on what matters most for defenders in the AI era. AI Is Getting Better at Security, and That Changes Everything One of the strongest themes of the conference was how quickly AI models are improving at security-related tasks. Irregular shared examples from their work evaluating frontier models on security challenges. One example stood out: an earlier model could correctly identify a vulnerability, such as a buffer overread, but then try to exploit it as if it were a buffer overflow, likely because buffer overflows are more common in training data. That mistake captures the strange state of AI security today. The models can reason about code, but they can still generalize incorrectly in critical ways. The important insight is that these weaknesses are improving fast. As models become better at vulnerability research, exploit development, triage, detection engineering, and defensive automation, security teams will need to rethink how they work. Another key point was fine-tuning. In some cases, spending time fine-tuning a model may become less valuable if the next general-purpose model is already much stronger out of the box. Takeaway: AI is becoming a real security capability, not just a productivity tool. Defenders need to understand both its strengths and its failure modes. Context Engineering Matters More Than Model Magic Vega’s talk showed a practical example of AI for blue-team work. They built an AI system for SOC use cases, where the challenge was making sense of huge amounts of security logs. The simple approach, sending all logs to an LLM, does not work. There is too much data, and it quickly exceeds any useful context window. Instead, they used the model’s ability to write code. The LLM generated code that selected relevant information from logs stored in S3. That code ran in a sandbox and extracted the right context before passing it forward. The core lesson was clear: even powerful models cannot compensate for bad context. Takeaway: Good AI security systems are not just about choosing the best model. They are about building the right pipeline around the model: context selection, structure, execution, validation, and control. Multimodal AI Needs the Right Preprocessing Ran Bar-Zik’s talk showed how preprocessing can help a multimodal model understand what a human is doing inside an RDP session. The problem was fascinating: how can a system infer meaningful human activity from screen images in a security context? The talk also showed a very real part of working with multimodal models. Sometimes, a small preprocessing change can completely change the model’s understanding and response. Takeaway: Multimodal AI can be powerful for security monitoring, but raw data is often not enough. The way information is prepared for the model can be just as important as the model itself. Better Alerts Are Only the First Step Cyera’s talk focused on improving data leakage alerts. Instead of simply flagging potential issues, they used AI to help determine whether an alert was truly critical and explain why. What I liked most was the practical evolution of the solution. They started with a stronger and more expensive model to prove the problem could be solved. Then they optimized: switching securely to a cheaper model, improving caching, reducing token usage, and still giving customers better explanations. That is a very realistic AI journey. First, you prove that AI can solve the problem. Then you discover that cost, latency, caching, and token usage become serious engineering problems of their own. Takeaway: AI value is not only about accuracy. A real production AI system also has to be secure, efficient, explainable, and cost-effective. AI Can Help Defenders Understand Assets at Scale Claroty’s talk discussed using AI to recognize new types of IoT systems and improve asset and exposure evaluation. The model used product features together with a human-in-the-loop training process. This is especially important in IoT and OT environments. Many devices expose web interfaces, unusual services, and strange ports. That creates many opportunities for attackers, but it also makes asset understanding much harder for defenders. Takeaway: You cannot secure what you do not understand. AI can help defenders classify, enrich, and prioritize assets at scale, especially in complex environments. CVE Fatigue Is Real Dream’s talk addressed a problem many security teams know too well: CVE fatigue. There are more and more CVEs, and organizations constantly need to decide what to fix first, what can wait, and what is actually exploitable in their environment. Their system maps exploitability conditions and system behavior to help customers prioritize vulnerabilities more effectively. This direction is important because CVSS alone is not enough. Real risk depends on context: exposure, configuration, exploitability, compensating controls, and business impact. This topic resonated with me personally. As part of the security research team responsible for F5 attack signatures and threat campaigns, we constantly need to filter CVEs by urgency, severity, exploitability, customer relevance, and trendiness. AI can help, but only if it is grounded in real context. Summarizing CVE descriptions is not enough. Takeaway: Vulnerability prioritization needs to move from “how severe is this CVE?” to “how relevant and exploitable is this in my environment?” Offensive AI Combines New Interfaces With Old Bugs Several talks focused on the offensive side of AI security. One strong example showed how boundaries between SearchGPT and ChatGPT-like behavior could be abused. The attack combined prompt injection with a traditional bypass of a url_safe function that was supposed to prevent calls to non-whitelisted domains. That combination is important. AI security issues often look new, but many of them still rely on familiar security mistakes: weak trust boundaries, broken URL validation, allowlist bypasses, and unsafe tool use. Takeaway: AI does not replace traditional AppSec problems. It often wraps them in a new interface and makes their impact harder to predict. Guardrails Are Necessary, but Not Enough Guardrails matter. They reduce obvious risks and block many unwanted behaviors. But guardrails alone cannot secure AI agents. If we do not monitor what agents do inside the loop (every tool call, every context change, and every place where external data can influence behavior) we miss the bigger picture. Organizations are moving fast to build AI-powered systems. As usual, security often comes later. With AI, it may come even later than usual. That makes proper identity management, permissions, and monitoring for agents non-negotiable. Takeaway: Securing AI agents requires more than prompt-level protection. It requires identity, authorization, observability, and control over every action the agent can take. RAG Poisoning Is Not Going Away Idan Hubler’s talk introduced HubScan, an open-source tool designed to detect “hubs” in retrieval systems. Hubs are sources that have a high chance of being retrieved across many user queries. That makes them especially dangerous in RAG poisoning scenarios. If an attacker can poison a highly retrievable source, the impact can spread widely. RAG is becoming a core part of many AI products, including tools from major companies. That means RAG poisoning is not a niche problem. It is an attack surface defenders need to understand. Takeaway: In RAG systems, not all documents have equal risk. Highly retrievable sources deserve special attention because poisoning them can influence many outputs. MCP Servers: Fast Innovation, Familiar Security Problems Neta Ravid from Astrix Security gave a talk about MCP servers done wrong. The talk showed how quickly development can move ahead of security. During a small internal hackathon using MCP to improve workflows, they discovered that many MCP servers encouraged static authentication and hardcoded credentials instead of secure secret handling through environment variables or vaults. Takeaway: New AI infrastructure often repeats old security mistakes. The technology may be new, but secrets management, authentication, and least privilege still matter. More AI Means More Code, and More Attack Surface The final talk, from Wiz’s VP of AI, focused on how hacking is becoming more democratized. With enough tokens, more people can hack, generate exploits, and move faster when a new one-day vulnerability is published. But the defensive implication is just as important: AI also means more people inside organizations can write code. It is no longer only R&D building applications. HR, operations, marketing, and other teams may now create internal tools with AI assistance. For example, an HR team might build a small gift-management app that accidentally exposes employee data. This changes the AppSec problem. Security teams will need better visibility into where code is being created, who is creating it, and what risks it introduces. Takeaway: AI expands the attack surface not only by helping attackers, but also by enabling more internal code creation across the organization. Conclusion What I love about conferences, beyond meeting people, is that they expose you to problems and ideas you did not even know others were working on. Some talks are partly company PR, and in some way, every conference talk is. But hearing how different teams approach real security problems gives you new perspective. It makes you return to your own work with more motivation and better questions. CyberML was full of practical examples, new risks, and useful reminders. The biggest message I took from the conference is this: AI is not just another tool added to security workflows. It changes the workflows themselves. It changes how attackers move, how defenders prioritize, how alerts are explained, how assets are understood, how code is created, and how systems need to be monitored. For defenders, the challenge is not only to use AI. It is to understand where AI changes the threat model, where it creates new exposure, and where it can genuinely help us make better security decisions.November Security Research Update: Newly Released Attack Signatures
Executive Summary Recent disclosures have introduced a wide range of vulnerabilities across major ecosystems, including critical pre-authentication RCEs, deserialization flaws, SQL injection vectors, path traversal issues, and several authentication-bypass techniques. In response, the Security Research Team published targeted CVE signatures and refined numerous general protections to address bypass attempts and new exploitation patterns. While several November releases included targeted CVE-focused signatures, F5’s WAF protections extend far beyond CVE coverage. Our signatures are designed to stop classes of attacks, block bypass techniques, and detect real-world exploitation behaviors that are not tied only to a specific CVE. The sections below highlight the most significant protections added this month. New Attack Signatures Oracle Identity Manager Pre-Auth RCE - CVE-2025-61757 This critical pre-auth RCE (CVSS 9.8) in Oracle Identity Manager is highly attractive for mass exploitation due to public PoCs. Researchers discovered a bypass in the product’s security filter, which whitelisted any endpoint ending in .wadl to allow access to API specification files. Because getRequestURI() function in Java returns the URI without query parameters but preserves matrix parameters, appending ;.wadl to any path and bypass authentication. Using this auth bypass, they reached an endpoint that compiles Groovy code. While compilation alone seems harmless, the @ASTTest annotation allowed code execution during compilation, resulting in a full pre-auth RCE. We have released a new attack signature, Signature ID 200204047, to block any malicious request trying to exploit this vulnerability. OAuth2-Proxy Header Smuggling Vulnerability - CVE-2025-64484 Smuggling issues continue to resurface across ecosystems. This release adds coverage for a high-severity OAuth2-Proxy vulnerability (CVSS 8.5) that enables request manipulation and potential privilege escalation via the X-Forwarded-For header. Although OAuth2-Proxy removes the standard X-Forwarded-For, it fails to strip underscored variants (e.g., X_Forwarded_For). Some backend servers treat these as equivalent to the hyphenated header, enabling header smuggling and bypassing proxy mitigations. A similar issue appeared a decade ago in CVE-2015-0219 (WSGI header spoofing) with X-Auth headers, which is already mitigated by signature 200013001. We have released a new attack signature, Signature ID 200013145, to block any malicious request trying to exploit this vulnerability. Monsta FTP Remote Code Execution - CVE-2025-34299 Monsta FTP servers exposed to the internet have long been a common target for attackers. In this new exploit, attackers abuse the downloadFile function to pull files from an attacker-controlled SFTP server directly onto the Monsta FTP host. This effectively enables arbitrary file uploads (including malicious payloads) which can then be executed to achieve full remote code execution. We have released a new attack signature, Signature ID 200020235, to block any malicious request trying to exploit this vulnerability. Chef Automate SQL Injection - CVE-2025-8868 A high-risk SQL injection vulnerability was discovered by Xbow: an AI-based security researcher. Xbow identified a default token exposed in a GitHub repository, authenticated with it, and accessed previously protected API endpoints. One of these endpoints, a search API that accepted a filters array, was vulnerable to SQL injection and leaked PostgreSQL error details. and the CVE signature We have released a new attack signature, Signature ID 200102194, to block any malicious request trying to exploit this vulnerability. WSUS Unauthenticated RCE - CVE-2025-59287 This high-severity vulnerability stems from insecure deserialization via SoapFormatter. By sending an SOAP document containing a serialized malicious object in the MiscData tag, the server performs deserialization without any additional validation, leading to remote code execution. We have released a new attack signature, Signature ID 200204044, to block any malicious request trying to exploit this vulnerability. Magento RCE - CVE-2025-54236 Magento’s deserialization mechanism is quite unique, and its nested deserialization has previously led to the critical CVE-2024-34102 (mitigated by F5’s attack signature 200018190). In this vulnerability, the researchers managed to override the file path where serialized sessions are stored. Combined with an existing file-upload feature, this makes the application deserialize a malicious PHP object, ultimately achieving an unauthenticated RCE. We have released a new attack signature, Signature ID 200204046, to block any malicious request trying to exploit this vulnerability. Fortinet FortiWeb Path Traversal - CVE-2025-64446 This high-severity vulnerability is a path traversal chained with an authentication bypass. The path traversal allowed the attackers to access /cgi-bin/fwbcgi, which is a CGI executable that allowed them to impersonate a high-privilege user and carry out privileged operations. and the CVE signature We have released a new attack signature, Signature ID 200007106, to block any malicious request trying to exploit this vulnerability. WSO2 API Manager Authentication Bypass - CVE-2025-10611 Matrix parameters trick to bypass authentication, once again. The developers relied on a regex to block access to certain endpoints. The researcher discovered multiple bypasses, including one that abuses the fact that access to URLs ending with /.well-known/openid-configuration is whitelisted. Here, appending ;/.well-known/openid-configuration didn’t bypass the filter, because the regex explicitly blocks; followed by / (due to previous CVE on this product). The researcher instead used ;%2F.well-known%2Fopenid-configuration. This works because the URI gets decoded only after the regex check, allowing the bypass to succeed. Figure 3: CVE-2025-10611 exploitation attempt blocked by F5 WAF We have released a new attack signature, Signature ID 200013143, to block any malicious request trying to exploit this vulnerability. Triofox Authentication Bypass - CVE-2025-12480 By simply setting the Host header to localhost, attackers were able to bypass access-control checks and reach internal functionality within AdminAccount.aspx. This allowed them to create an admin user on the system and ultimately abuse the Triofox anti-virus feature to upload and execute malicious payloads. We have released a new attack signature, Signature ID 200013144, to block any malicious request trying to exploit this vulnerability. In general, you can block any requests containing Host header with a localhost value in the Big IP by turning on the illegal host name violation. Conclusions The vulnerabilities covered in this release largely stem from recurring patterns: inconsistent request parsing, unsafe deserialization paths, regex-based filters that miss normalization edge cases; and trust in controllable headers or parameters. These weaknesses enabled attackers to chain simple bypasses into high-impact outcomes such as pre-auth RCE, SQL injection, path traversal, and privilege escalation, often aided by publicly available PoCs. In response, we added CVE-specific signatures and refined general protections to better detect smuggling behavior, deserialization abuse, traversal attempts, and other techniques observed in real-world traffic. To maximize protection, we recommend reviewing your current security policy to ensure the relevant signature sets are enabled for your applications, and follow best practices. Stay safe. See you in the next update.
