When CISA issues an emergency directive, the message to every federal agency and every security team paying attention is to patch now. For CVE-2026-50751, a CVSS 9.3 authentication bypass in Check Point Remote Access VPN, that directive landed on June 21. despite exploitation beginning in early May. That, six-week active intrusion gap is not a footnote. It is the entire story.

The flaw itself is straightforward in the worst possible way. A logic error in the certificate-validation process, triggered when the deprecated IKEv1 key-exchange protocol is enabled, allows a remote attacker to establish a fully authenticated VPN session without a valid password. No phishing. No credential theft. No lateral movement required to reach the perimeter. The attacker walks through the front door, and the door logs it as a legitimate entry.

By the time Check Point disclosed the vulnerability on June 8, a Qilin ransomware affiliate had already used it to compromise a few dozen organizations worldwide. The post-access playbook was efficient, including Rclone for data exfiltration, the Tox protocol for command-and-control communication routed through disposable VPS infrastructure. Quiet, fast, and designed to complete the job before detection had a chance to matter.

The security product became the attack vector

There is a particular irony to CVE-2026-50751 that the industry needs to sit with. The device that was breached is not an unpatched workstation or a misconfigured cloud bucket. It is the VPN gateway, the product sold specifically to keep attackers outside the perimeter. The control designed to prevent unauthorized access became the mechanism of it.

This is not unique to Check Point, and it is not a criticism of any single vendor. It reflects a structural problem with perimeter-dependent security architecture. When the perimeter device is the trust anchor, compromising that device does not just breach the perimeter. It inherits the perimeter’s authority. Every downstream control, every identity verification, every behavior-based detection tool is now reasoning about a session it believes is legitimate, because the VPN said so.

That is the condition Qilin exploited. And patching the vulnerability, while absolutely necessary, does nothing to change the position of organizations that were breached during the May-June window. For them, the attacker is already operating as a trusted user. The CISA directive is not a remedy for those organizations. It is a message to everyone else.

Why the standard response falls short

The standard sequence after a disclosure like this is one we’ve all heard before—patch the affected systems, update detection signatures, review logs for indicators of compromise. While each of these steps is good practice, none of them solves the underlying problem.

Patching closes the door for future attackers, but it does not evict the ones already inside. Detection signatures help identify known post-exploitation behavior, but ransomware affiliates have demonstrated consistent operational discipline, using legitimate tools for exfiltration and standard protocols for command-and-control precisely because these approaches blend into normal traffic. Log review is valuable, but the attackers who exploited the vulnerability had weeks of access before anyone was looking.

The detect-and-respond model assumes that detection arrives before the damage is complete. Against a weaponized zero-day with a six-week head start, that assumption does not hold. By the time an alert fires, the data has moved. The ransomware is staged. The ransom clock has started.

Making the endpoint harder to exploit

The Check Point vulnerability forces a critical question: how do you stop payload execution when an attacker has already succeeded at authentication and bypassed every other defense?

It requires moving the defensive layer to the endpoint itself, at the point of execution, where the ransomware payload has to operate regardless of how access was obtained. Techniques that morph the runtime memory environment, transforming the structures that malware needs to find and use at execution time, stop the payload deterministically. The attacker can have authenticated credentials, a legitimate session, and weeks of undetected access. If the target environment does not look like what the payload expects, the payload fails.

This is not a replacement for patching. Organizations should apply the Check Point fix immediately, and they should treat any system with IKEv1 enabled during the May-June window as potentially compromised. But patching is the beginning, as the organizations that were inside the six-week exploitation window need a control that works after the perimeter is gone.

The lesson before the next directive

CISA will issue another emergency directive. There will be another authentication bypass, another perimeter device turned attack vector, another financially motivated threat actor with a head start measured in weeks. The patch-and-detect cycle will play out again, and organizations that had their exposure managed entirely at the perimeter will find themselves in the same position.

The lesson here is not that Check Point failed or that VPNs are over. It is that any architecture where a single authentication bypass gives an attacker operating authority over the entire environment has a structural problem that no patch resolves. Closing the door is necessary. Making sure the ransomware cannot detonate even after the attacker is inside is the part the industry still has not solved at scale.

That is the conversation the CISA directive should be starting, and mostly is not.

The post Why patch directives only go so far appeared first on CyberScoop.

The federal agency tasked with analyzing security vulnerabilities is overwhelmed as it and other authorities struggle to keep pace with a flood of defects that grows every year. The National Institute of Standards and Technology announced Wednesday that it has capitulated to that deluge and narrowed the priorities for its National Vulnerability Database.

NIST said it will only prioritize analysis for CVEs that appear in the Cybersecurity and Infrastructure Security Agency’s known exploited vulnerabilities catalog, software used in the federal government and critical software defined under Executive Order 14028.

The federal agency’s goal with the change is to achieve long-term sustainability and stabilize the NVD program, which has encountered previous challenges, notably a funding lapse in early 2024 that forced NIST to temporarily stop providing key metadata for many vulnerabilities in the database.

The agency still hasn’t cleared a backlog of unenriched CVEs that built up during that pause and grew since then. 

NIST said it analyzed nearly 42,000 vulnerabilities last year, adding that CVE submissions surged 263% from 2020 to 2025. “We don’t expect this trend to let up anytime soon. Submissions during the first three months of 2026 are nearly one-third higher than the same period last year,” the agency said in a blog post announcing the change. 

Indeed, vulnerabilities are increasing across the board. For instance, Microsoft addressed 165 vulnerabilities Tuesday, its second-largest monthly batch of defects on record.

NIST said CVEs that don’t fit its more narrow criteria will still be listed in the NVD, but they won’t be automatically enriched with additional details. 

“This will allow us to focus on CVEs with the greatest potential for widespread impact,” the agency said. “While CVEs that do not meet these criteria may have a significant impact on affected systems, they generally do not present the same level of systemic risk as those in the prioritized categories.”

Researchers and threat hunters who analyze vulnerabilities for CVE Numbering Authorities (CNA) and vendors that publish their own assessments view NIST’s new approach as inevitable.

“They had to do something. NIST was woefully behind on classifying CVEs and would likely never have caught up,” Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, told CyberScoop.

“I’m not sure if it was a herculean task or a sisyphean one, but either way, they were set up for failure under their previous system. This change allows them to prioritize their work,” he added.

NIST’s new approach will impact the vulnerability research community at large, but also put more private companies and organizations in a position to gain more authority as defenders seek out more alternative sources.

Caitlin Condon, vice president of security research at VulnCheck, previously told CyberScoop that prioritization remains a problem, with too many defenders paying attention to vulnerabilities that aren’t worth their time. 

Of the more than 40,000 newly published vulnerabilities that VulnCheck cataloged last year, only 1% of those defects, just 422, were exploited in the wild. 

NIST is also trying to reduce other duplicitous efforts with its new approach, effectively leaning even more on CNAs. CVEs that are submitted with a severity rating will no longer receive a separate CVSS score from NIST, the agency said. 

While the agency remains the ultimate authority providing a government-backed catalog of vulnerability assessments, it acknowledged these changes will affect its users.

“This risk-based approach is necessary to manage the current surge in CVE submissions while we work to align our efforts with the needs of the NVD community,” the agency said. “By evolving the NVD to meet today’s challenges, we can ensure that the database remains a reliable, sustainable and publicly available source of information about cybersecurity vulnerabilities.”

The post NIST narrows scope of CVE analysis to keep up with rising tide of vulnerabilities appeared first on CyberScoop.

A maximum-severity vulnerability in pac4j, an open-source library integrated into hundreds of software packages and repositories, poses a significant security threat, but has thus far received scant attention.

The defect in the Java security engine, which handles authentication across multiple frameworks, has not been exploited in the wild since code review firm CodeAnt AI published a proof-of-concept exploit last week. The company discovered the vulnerability and privately reported it to pac4j’s maintainer, which disclosed the defect and released patches for affected versions of the library within two days.

Some researchers told CyberScoop they are concerned about the vulnerability — CVE-2026-29000 — because it affects a widely deployed Java security engine that attackers can exploit with relative ease.

“A threat actor only needs to access a server’s public RSA key to attempt exploitation,” researchers at Arctic Wolf Labs said in an email. 

These public keys, which are shared openly, are used to encrypt data and enable identity authentication. Attackers can trigger the defect and bypass authentication by forging a JSON Web Token (JWT) or deploy raw JSON claims via JSON Web Encryption (JWE) in pac4j-jwt to break into a system with the highest privileges.

“It is currently too early into the lifecycle of this vulnerability to tell if it will materialize into a major threat but the fact that it is a vulnerability in a library makes it more challenging to assess the potential risk,” researchers at Arctic Wolf Labs said. “Downstream consumers of the library may end up needing to issue their own advisories, as we’ve seen with other similar vulnerabilities in the past.”

Amartya Jha, co-founder and CEO at CodeAnt AI, warned that anyone with basic JWT knowledge can achieve exploitation. The vulnerability is a “logic flaw that no pattern-matching scanner or rule-based static application security testing tool would surface, because there’s no single line of code that’s wrong.”

The downstream security risk, as is often the case with open-source software, is widespread. The authentication module for pac4j is integrated into multiple frameworks, including Spring Security, Play Framework, Vert.x, Javalin and others, Jha said.

Many organizations may not realize they depend on pac4j-jwt because it’s not always declared in build files, he added. CodeAnt said it has contacted hundreds of maintainers in the past week to warn them that their packages and repositories are impacted by the vulnerability, which has a CVSS rating of 10.

Researchers haven’t observed any additional PoC exploit code, but they noted the exploit path is easy to reproduce. 

“The conditions for exploitation are favorable,” Jha said. “It’s pre-authentication, requires no secrets, the PoC is public, and the attack surface includes any internet-facing application or API gateway using the affected configuration. The window between public PoC and patch adoption is where the risk is highest.”

The post Critical defect in Java security engine poses serious downstream security risks appeared first on CyberScoop.