Attackers have started exploiting a maximum-severity GitLab vulnerability patched earlier this month, according to the US Cybersecurity and Infrastructure Security Agency (CISA). Tracked as CVE-2026-97229, this critical security flaw was discovered by a security researcher using the 'joaxcar' handle in the CI/CD Regular Expression Compiler, which parses, compiles, and evaluates regular expressions in pipeline configuration files. CVE-2026-97229 stems from an integer overflow weakness and could let remote attackers run arbitrary code on targeted instances via a maliciously crafted regular expression in a CI/CD configuration, due to insufficient expression validation. "GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation," it said.
A practical pentest workflow combines CVSS, EPSS and business impact to validate findings, prioritize fixes and document remediation decisions. Remediation prioritization after a pentest is the process of ranking and ordering security findings based on their risk, exploitability, and business impact. A penetration test can produce any number of findings, ranging from the very low (zero) to the very high (hundreds). The security of the tested organization depends on the findings management processes addressing the most important results first. CVSS alone misranks risk. Accurate prioritization relies on combining CVSS, EPSS, and business context. 68.4% of practitioners say a 500+ candidate finding set would strain the team or be unmanageable, so it’s important to validate first. 81.7% of practitioners see AI-generated findings that need significant manual validation, so validation with concrete proof remains essential. Document every deprioritization, because that record counts as audit evidence. Why aren’t CVSS scores alone enough to inform remediation? When prioritizing pentest results, some practitioners rely solely on frameworks like the Common Vulnerability Scoring System (CVSS). The logic is sound: the higher a vulnerability’s CVSS score is, the more risk it poses, and the sooner you should fix it, right? Unfortunately, the reality is much more complicated. Boiling down a complex ecosystem of risk into a one-dimensional number means ignoring the wider business context. In the end, that means you fix vulnerabilities that pose serious theoretical risk first, while genuine exposures get pushed to the back of the queue. Lets use two hypothetical vulnerabilities as an example. Vulnerability A is an RCE flaw, CVSS 9.8, on an isolated intranet site. Vulnerability B is a BOLA flaw, CVSS 6.5, on a public facing production payment API. Now think about which one you would fix first. Would you prioritize the“critical” flaw on an intranet site, containing no sensitive data that attackers could only reach if they’d already compromised your internal network? Or would you prioritize the “medium” flaw on an API that processes live credit card transactions, and that any script kiddie could manipulate? Across an entire organization, or multiple organizations if you’re a consultant or MSP, those critical flaws can really pile up. In one AI pentesting survey of 158 base practitioners by Pentest-Tools.com, conducted in June 2026, 68.4% of respondents said a 500+ candidate finding set would strain the team or be unmanageable. Approaching risk prioritization by trying to fix every “Critical” finding is going to exhaust you and your team. That’s when people make mistakes, and you end up with a major incident on your hands. What separates a validated finding from a candidate? That same distinction, in part, separates a candidate finding from a validated one. For example, vulnerability with a high CVSS score but near-zero exploitability should remain a candidate. To graduate a vulnerability from a candidate to a legally and technically validated finding, it must pass through a strict filter that involves three processes. The first step is to eliminate as much administrative noise as possible. That means deduplicating findings and removing any that are obviously non-exploitable. Then, you need to confirm exploitability. That typically means executing a safe, controlled attack path against the target environment to prove that a state change, data exposure, or privilege escalation can actually occur. Finally, you need concrete evidence. A validated finding cannot rely on a generic tool’s “confidence score.” It must include comprehensive proof that a developer or auditor can immediately follow: Technical proof tends to include HTTP request/response traces or specific error payloads. Proof of impact includes things like screenshots or server-side telemetry demonstrating unauthorized data access. Now, many vendors are going to claim that AI-generated findings ease the strain of exploit validation. In many cases, they’re telling the truth. But as with any AI technology, a healthy level of skepticism is important. According to the same study, 81.7% of respondents encounter AI-generated findings that need significant manual exploit validation at least sometimes. How do CVSS, EPSS and business context combine into a ranking? Together, CVSS, Exploit Prediction Scoring System (EPSS) scores, and business context create a single risk ranking that reflects real-world danger to the tested organization. CVSS, as mentioned earlier, measures theoretical severity. It tells you how bad a flaw is in a vacuum, but is entirely blind to context. EPSS measures probability. It tells you how likely an attacker is to exploit a flaw in the wild over the next 30 days, but doesn’t measure the potential impact of an exploitation. Business context measures operational impact. It tells you the value of the affected asset, how easily an attacker can reach a flaw, and what they can steal. It tells you nothing, however, about the threat itself. Ultimately, business context is expressed as residual risk, the danger left over after you factor in your existing defenses. Calculating it relies on measuring four factors: Exposure: Whether a server is open to the public internet. User count: How many people use a system. Data sensitivity: Whether the system holds sensitive information. Compensating controls: Whether you have firewalls or antivirus tools actively blocking the attack path. By checking these boxes, you won’t waste time fixing a “Critical” bug locked in an empty, disconnected server. Instead, you’ll prioritize the “Medium” bug on your public checkout page that hackers are actively trying to breach. What goes first when dev time is limited? Sometimes, you’re not going to have much time for remediation. That’s natural. In those situations, prioritize validated findings with high threat activity (EPSS score) and critical business exposure. They’re the findings that pose the most threat to your organization. Prioritization done well is itself evidence. A ranked, validated list, with a written reason for what was deprioritized, is what a team can defend later. You’ll need to record the owner (the specific individual accepting the risk), the date of the decision, the technical operational basis for deprioritization (such as an active compensating control), and a hard review date for re-evaluation. Why does the ranked list count as audit evidence? A prioritized ranking list counts as valid audit evidence because it proves compliance alignment with several major security frameworks. For example: ISO 27001 A.8.8 demands that organizations evaluate real-world exposure, take targeted corrective actions, and retain objective evidence that the remediation loop has successfully closed. PCI DSS 11.4 mandates that penetration testing actively validates and exploits findings, with formal retesting conducted after significant organizational changes. SOC 2 CC7.1 relies on this documentation to confirm that an organization maintains systemic operational consistency and rigorous vulnerability triage over time. A ranked, validated list also gives MSPs and MSSPs a clear, auditable record of truth that clients can either accept or challenge with their own evidence. This transparency ensures both sides agree on which real-world risks need to be addressed first. What does a defensible ranking record contain? A defensible ranking record contains the validated asset identification, its technical CVSS severity, its real-world EPSS probability, the active compensating controls defining its residual list, the formal sign-off from the risk owner, and the targeted review schedule. About the Author: Josh Breaker-Rolfe is a Content writer at Bora. He graduated with a degree in Journalism in 2021 and has a background in cybersecurity PR. He’s written on a wide range of topics, from AI to Zero Trust, and is particularly interested in the impacts of cybersecurity on the wider economy. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, pentest)
Microsoft has resolved Always On VPN connection failures triggered after installing the September 2026 Windows 11 security updates. The Always On VPN remote access solution runs in the background and establishes secure tunnels back to the user's corporate network when their devices connect to the Internet. It has replaced the legacy DirectAccess technology and supports domain-joined, non-domain-joined, and Microsoft Entra ID–joined devices running Windows 10, Windows 11, and Windows Server. Microsoft has previously mistakenly flagged this known issue as fixed in the October 2026 Windows 11 cumulative updates. The company first acknowledged it in a service alert sent to IT administrators in late September, saying the Always On VPN failures were triggered on Windows 11 systems by the September 2026 security updates when using automatic protocol selection with IKEv2 and SSTP.
Drupal warned admins to patch a critical access bypass vulnerability in the Commerce Core module that attackers are exploiting in the wild. Tracked as CVE-2026-118539, this flaw stems from a missing authorization weakness that can be abused by unauthenticated attackers and affects Commerce Core versions 0.0.0 through 2.41 and 3.0.0 through 3.3.13. The Drupal security team asked admins on the 3.x branch to upgrade immediately to Commerce Core 3.3.13 (or Commerce Core 8.x-2.41 for earlier versions) and audit orders for inconsistencies, since threat actors are exploiting this vulnerability in attacks. "This module enables you to sell goods and services to customers through an included shopping cart and checkout form or through decoupled applications via APIs," Drupal said in a Wednesday advisory tagged as highly critical.
A modern organization protects its information systems with a whole suite of technologies that generate thousands of security alerts every day. Looking at these alerts in bulk, you’ll see that a significant share are false positives. Ideally, these alerts would be filtered out automatically so that analysts could focus on the ones that may point to a real incident. However, writing filters is a time-consuming task in itself. To create a correct filter, an analyst needs to: Review the logs Identify the source of the activity Define filtering boundaries Choose filtering criteria Write a rule Check that the filter is robust This post looks at how filter creation itself can be automated to reduce analyst workload. Filter validity criteria In the context of security alerts, a filter is a combination of event field values that marks a detection as a false positive and not worth the analyst’s attention. Filters can be generated for any combination of event fields, but not every combination yields a valid filter. That’s why we need to define validity criteria: conditions showing that a specific filter actually removes noise and doesn’t suppress useful alerts. Detection rules in security systems typically contain a set of conditions, and each of them can generate an alert. A specific event triggers a given fragment of a detection rule. The set of events that a given fragment responds to is what we’ll call its context. A good filter should cover the entire context where possible, without going beyond it. Filters that are too broad or too narrow are useless. For example, a filter based solely on PowerShell would exclude too many events, including some that deserve the analyst’s attention. Most of the filtered events would also be unrelated to the rule in question. A filter on a specific ID, on the other hand, would cover only one event, which may never recur. Problems in filter generation We can run into a number of problems when creating filters. First, events often contain an excessive number of fields (around 400 on average), and most of them aren’t needed for filtering. At the same time, generating and ranking combinations of these fields is also fairly resource-intensive. So, the first step is to discard the irrelevant fields and keep only those worth using in the filter. For example, out of 400 fields in an event, four may be enough for filtering. Another problem is string normalization. Field values (for example, the path to the same application on different systems) can vary depending on system settings, user folder names, and so on. For a filter to account for all these variations, the strings must be normalized. For file paths, in particular, you can replace the drive letter and user folders with standard environment variables and convert all paths to a single case. Finally, if a filter completely mirrors the query of a detection rule, it effectively disables that rule. To fix this, remove the event fields used in the detection rule from the filter. For example, if a rule triggers on a file path, there are two ways to filter out unwanted alerts: In the filter, use fields other than the file path. Use a part of the file path that the rule doesn’t use. For example, for the rule file_path: ".../something.exe", you can set up a filter that excludes events with the user/unique_files/ directory in the file path. Filtering security alerts with an algorithm Given the problems described above, automatically generating filters for security alerts should consist of the following steps: An analyst receives a security alert that they assess as a false positive and uses the filter generator. The generator takes the 400-field event from the alert, along with the rule that triggered on it, and determines the context. The generator selects the fields that are relevant to the filter. The generator normalizes the strings. The generator builds different combinations of the selected fields. To do this, we applied the FP-Growth (frequent pattern growth) algorithm to the context determined earlier. FP Growth builds a tree of frequently occurring items (fields) from a dataset (in our case, the context) and discards items that aren’t frequent enough. This reduces the number of combinations to check, which lowers the cost of finding the most relevant ones. The generator ranks the resulting combinations and offers the analyst the top three to choose from. For example, consider an event described by the following JSON: After generating and ranking the combinations, we got three filters based on file paths: processcmdline:("nodejs\\node.exe" AND "*****\\appdata\\roaming\\npm\/node_modules\/pi-coding-agent\/dist\/cli.js") file_path:"*****/.pi\\agent\\bin\\fd.exe" processcmdline: "programfiles\\nodejs\\node.exe" The last filter turned out to be too broad, but the analyst marked the other two as valid. Pros and cons of the algorithmic approach The algorithmic approach to filter generation has several advantages. First, it’s simple and deterministic: the same alert always produces the same result. Second, it’s interpretable, meaning we can see why a given combination ranked near the top of the list and why a particular field didn’t make it into the list of candidate fields at all. Third, the stages of the process are independent of each other, so individual steps can be improved and tuned without the risk of breaking the algorithm elsewhere. Finally, it has no external dependencies or models, which makes it easy to deploy in any customer environment. However, it also has drawbacks. The first is its dependence on context. If there’s no context for some reason — for example, the rule’s first-ever trigger — a filter can’t be created. The second problem is string normalization. There’s a high chance of running into atypical cases that the normalization rules don’t cover. Often such cases can’t be described correctly at all, because they contradict each other. These problems can be solved with large language models (LLMs). When an LLM generates the filters, no context is needed, because the LLM doesn’t iterate over or rank combinations. The LLM also takes a more flexible approach to string normalization, including non-standard cases. That said, an LLM doesn’t have to be involved at every stage of the generation process. We decided to keep the algorithmic solution where it works well. For example, a simple algorithm selects suitable fields without errors, so we didn’t move this stage to the model. Filter generation with an LLM The LLM-based filter generation looks like this: The input is still an alert containing an event with 400 fields, plus the rule that triggered on that event. Then an algorithm selects the most suitable fields for the filter. Next, the LLM processes the input — the event, the selected fields, and the detection rule — and generates three filter options along with an explanation for them. The explanation helps the analyst understand why these particular filters were suggested and make an informed choice. Consider the following event in JSON format: The LLM suggested three filter options that all contain the same command line fragment: file_path: "\\WindowsPowerShell\\powershell.exe" AND filecmdline: "Get-VM -Name kafka\*" filecmdline: "Get-VM -Name kafka\*" filecmdline: "kafka*" As in the previous example, two of the three output filters were valid. The last one was too broad to be usable. The analyst chose the first filter with minor edits: file_path: "powershell.exe" AND filecmdline: "Get-VM -Name kafka\*" Pros and cons of generating filters with an LLM Using an LLM solved the problems of purely algorithmic filter generation: dependence on context and errors in string normalization. However, the single-request approach had its own drawbacks. First, it had no output validation. The LLM returned filters as-is, with no syntax check and no way to correct errors. Second, unlike in the algorithmic version, all filter generation tasks were handled by a single system prompt. As a result, a minor fix in one place could break the logic in another. Using multiple AI agents To address the problems of generating filters with a single model and a single system prompt, we tried distributing the tasks across different LLM agents. In this version, we brought in agents as early as the stage of selecting relevant fields. The chain includes four agents in total: Selector: selects the relevant fields. Generator: generates filters. Validator: evaluates the generated filters. If the filters are found to be invalid, it returns the task to the generator. If the selected fields are found to be irrelevant, it starts a new field selection cycle. If the filters pass validation, or the limit on regeneration attempts is reached, the valid filters (or the best ones available) are passed to the analyst. Commentator: analyzes the output filters and explains which field values were used and why. For the following JSON event, the agents produce three valid filters based on the file path. The filters differ in the additional parameters that support the detection: file_path:"sysvol\\domain\\scripts\\logon.bat" file_path:"sysvol\\domain\\scripts\\logon.bat" AND file_md5:"0x7..6E" autorun_entry: "Group Policy\\State" AND file_path: "SYSVOL\\domain\\scripts\\logon.bat" Pros and cons of the agent-based approach LLM agents give us a system that can validate and correct filters. Its modular architecture also lets us tune and improve different stages of generation independently. However, this approach makes more LLM calls than the previous ones, so the system is slower. It also depends on access to a model, which may not be available in the organization’s isolated environment. Evaluating the filter generation system To evaluate how well the filter generation system works, we use two main metrics: Approval rate. For each security alert, the system suggests three filters. If the analyst selects at least one of them, we count the generation as successful. For example, in the case below, the approval rate is 2/3. False positive reduction rate (FP drop). This metric shows how much a filter helps reduce the number of false positives. It can only be measured over time, because we need to compare the number of false positive alerts received during a set period before and after the filter is deployed. Below is a comparison of the three filter generation approaches by these metrics: As the results show, LLMs significantly improve the efficiency of filter generation. At the same time, the LLM agentless and agent-based approaches perform almost identically. So we chose the simpler and faster option: an LLM with a single system prompt. As a result, we cut false positives by 99%, increased the number of filters generated per day by 28%, and made analysts’ alert handling 17% more efficient. Takeaways Practice has shown that filter generation can be automated effectively. We’ve looked at several options for automatically generating filters for false-positive security alerts: a purely algorithmic approach, an LLM-based approach, and an approach built on a group of LLM agents. All of them can generate valid filters and make the analyst’s work much easier, but each has its own pros and cons. The algorithmic approach scored lower on the evaluation metrics, but in two-thirds of cases, it still produces filters that satisfy the analyst. It works especially well when there’s already a set of similar events to filter out, meaning enough context has accumulated. The algorithmic generator can also be deployed in any environment. Both standalone LLM and multi-agent LLM approaches show high accuracy, and their results differ only slightly, so the slower agent-based approach looks excessive at this stage. If an LLM is available, the best option appears to be a single model that handles several stages of the generation cycle.
A hacker leaks personal data on more than 40,000 DHS employees, including CBP, ICE and CISA staff, after an undisclosed breach. Personal details of thousands of U.S. Department of Homeland Security (DHS) employees are now online after a hacker stole reams of data in a data breach that occurred earlier this year and nobody had disclosed. “The breach includes names, job titles, and work contact information, such as email addresses, cell phone numbers, and office locations, of more than 40,000 people who work for the federal department, including border and immigration agents, cybersecurity staffers, and senior department officials.” TechCrunch reports. The incident impacted border and immigration agents, cybersecurity staff and senior department officials. DHS confirmed it is aware of a potential breach and is investigating, saying it takes threats to employees seriously and will provide updates when more information is available. “DHS is aware of a potential breach and is actively working to address the situation swiftly and effectively. We take all security threats against our employees and officers seriously and will work to ensure all are properly protected. We will update the public when more information is available,” a DHS spokesperson told SecurityWeek. The hacker, who uses the name Department of Peace, claims to have stolen the data from an Okta single sign-on system. DHS uses this service to give employees and contractors across its agencies access to the department’s central network. The system also stores IT and login records for each account, showing which systems and internal apps each person can access. The hacker left a note with the leaked data, seen by TechCrunch, saying that if others have their information, it is only fair to share theirs. The malicious actor did not reveal how the U.S. agency was breached. More than half of the records, around 21,000, belong to U.S. Customs and Border Protection (CBP) employees working at airports and other ports of entry. Another 10,000 belong to Immigration and Customs Enforcement (ICE) and its Homeland Security Investigations unit, while just under 1,000 are linked to the cybersecurity agency CISA. Thousands of other records belong to DHS headquarters and agencies such as U.S. Citizenship and Immigration Services and the Federal Protective Service. DDoSecrets says the leaked database identifies officials involved in undercover operations and key DHS personnel overseeing renditions and deportations. Department of Peace said the leak was a response to the government’s actions against ICE. Crimew described the database as an unprecedented view of DHS’s organizational structure, helping researchers identify employees, their roles and reporting lines. They said it could also support investigations and future Freedom of Information Act (FOIA) requests. DDoSecrets co-founder Emma Best said the database, called Icepick, identifies officials involved in covert operations, internal investigations and deportation programs. Ryan Shapiro of Property of the People added that employee contact details could help researchers submit more targeted FOIA requests. Best said the data could also support journalism, congressional inquiries, legal challenges and community investigations. “Rather than an indiscriminate directory of every DHS employee, Icepick identifies many of the architects and drivers of DHS policy and operations,” said journalist and DDoSecrets cofounder Emma Best. “The leak is extraordinary but deceptive in its simplicity as it identifies the officials responsible for overseeing covert and undercover operations, the government’s hunt for leakers and the failed BlueLeaks investigation — along with key personnel in DHS’s ever-escalating rendition and deportation programs.” “By replacing the regime’s anonymity with accountability, Icepick and the tool developed by maia are catalyst for investigations, empowering journalists, Congressional inquiries, legal challenges, community action and Freedom of Information Act requests,” added Best. DHS is investigating a potential breach. Okta says it has no evidence its systems or data were compromised. The breach follows other attacks on U.S. government agencies that exposed FBI records and military personnel data. It is also the second DHS breach this year, after the same hacker claimed to have stolen thousands of government contracts. Journalist maia arson crimew shared the data with DDoSecrets. TechCrunch verified some records, which suggest the database was copied around mid-August. The leak covers about one-fifth of DHS’s 220,000 employees. The records reveal access to tools including Microsoft 365, ChatGPT, Penlink surveillance software and Mobile Fortify, a facial recognition app used by CBP and ICE. Around 4,500 accounts belong to a Headspace user group, while more than 2,000 Homeland Security Investigations employees appear in Penlink-related groups. Researchers say the contact details could help journalists file targeted Freedom of Information Act requests. However, exposing employees’ phone numbers and office locations also creates security and privacy risks. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, DHS)
A Trezor Safe 5 hardware wallet bought from the reseller CryptoBilis has an extra circuit board that sends out the recovery phrase over a mobile network, a customer has reported. Trezor has not yet examined the device. It is telling everyone who bought a Trezor from CryptoBilis since March 2026 to move their funds to a new wallet with a new recovery phrase. Trezor said in a blog post&nbsp
The alert is critical. The fix is known. And the ticket sits in a queue for days. Security teams understand the risk, but the people who keep applications available need proof that the change won’t break anything. Their concerns are practical. An IPS protection could block legitimate traffic. A configuration change could interrupt a service. An endpoint policy could affect an application
Ahmad Umar Agha, a Syrian Electronic Army hacker known online as "Th3Pr0," has been sentenced by a U.S. federal court to 42 months in prison for his role in a hacking conspiracy that targeted Western news outlets. The conspiracy was organized and led by members of former Syrian President Bashar al-Assad's inner circle, including the commander of Syria's General Intelligence
Cybersecurity researchers have disclosed that a trojanized version of Anthropic's official Claude Code extension was distributed through the Cursor Marketplace as a legitimate update, attempting to install a persistent SSH backdoor on affected systems. The malicious update, version 2.1.313, was distributed under the extension's legitimate publisher identity, prompting Cursor to temporarily shut
Confirm this action.
Leaving now will discard your changes.