The CRA’s scope for open-source software (OSS) was one of the most contested parts of the regulation. The OSS community raised legitimate concerns during the legislative process such as how should manufacturer obligations apply to non-commercial, volunteer-driven projects? The final regulation offers an answer, though how convincing that answer is depends on who you ask. Since March 2026, the European Commission’s (EC) first draft guidance has started to clarify the details.

For companies like Greenbone that both steward an open-source project (OPENVAS) and sell commercial products built on it, the answer is clear: full manufacturer obligations apply to the commercial side, and steward obligations apply to the open-source community activities. Knowing where those lines fall is important.

Open Source & CRA

The CRA’s Three-Tier Approach to Open-Source Software

Tier 1: Non-Commercial Open-Source Projects and Their Contributors (Out of Scope)

Free and open-source software (FOSS) developed and distributed in a purely non-commercial context (i.e. volunteers building software and sharing it freely, with no commercial intent or support model) does not impose CRA obligations on its creator or distributor. Only FOSS supplied in the course of a commercial activity falls in scope, and the EC’s draft guidance confirms that merely supplying non-monetized FOSS is not a commercial activity.

That said, “non-commercial” is still perhaps more narrowly defined than many projects assume. Accepting donations does not automatically make a project commercial. However, (EU) 2024/2847 Recital 15 states that “accepting donations exceeding the costs associated with the design, development and provision” does constitute commercial activity. The EC’s draft CRA guidance and (EU) 2024/2847 Recital 18 also state that the CRA does not apply to individuals or companies that merely contribute source code to FOSS projects that are not under their responsibility.

Tier 2: Open-Source Software Stewards (Lighter Obligations)

The CRA introduces the legal definition of an “open-source software steward”: a legal person that provides sustained, systematic support for the development of open-source products intended for commercial activities, or ensures those products’ viability. This covers software foundations, industry consortia, and companies that maintain and support OSS projects used commercially by others. A natural person is not classified as an OSS steward under (EU) 2024/2847 Article 3(14).

Stewards do not face the full obligations that manufacturers do. Their obligations are lighter than full manufacturer requirements: no CE marking, no formal conformity assessment, no required retention of technical documentation. However, under (EU) 2024/2847 Article 24, open-source software stewards must still:

• Maintain a cyber security policy that fosters secure development of the OSS products they support
• Cooperate with market surveillance authorities and make security documentation available on request
• From 11 September 2026, report actively exploited vulnerabilities and severe security incidents that affect the network and information systems provided for development of their OSS products
• Effectively remediate vulnerabilities and ensure they are accessible to users without undue delay
• Establish a policy that fosters voluntary vulnerability reporting by the developers of the software product

Stewards are also exempt from administrative fines for CRA infringements under Article 64(10). Enforcement works through cooperation and corrective measures rather than financial penalties.

Tier 3: Commercial OSS Vendors (Full Manufacturer Obligations)

If an individual (natural person) or legal person (such as a company or other type of organization) develops and distributes OSS and places it on the EU market in the course of commercial activity, they qualify as a manufacturer under the CRA. The CRA’s threshold for “commercial activity” is broad. It is not only about selling a license. Providing paid support, SLA-backed hosting, or professional services built around an OSS product also constitutes commercial activity under the CRA. All Annex I requirements apply to manufacturers: secure-by-default design, vulnerability handling, 24-hour incident reporting, SBOM, technical documentation, and CE marking.

Manufacturers remain responsible for vulnerability handling in their own products, including vulnerabilities caused by integrated third-party OSS components. (EU) 2024/2847, Article 13 specifies that manufacturers must exercise due diligence when integrating third-party components. Upon identifying a vulnerability in an integrated component, including an FOSS/OSS component, they must report the vulnerability to the person or entity manufacturing or maintaining that component and, without delay, remediate the vulnerability in accordance with (EU) 2024/2847 Annex I, Part II.

The EC’s March 2026 Draft Guidance: What We Know Now

The public feedback period for the EC’s March 2026 draft guidance closed on 31 March 2026. Some edge cases remain unclear, although final guidance is expected later in 2026. Organizations should revisit any scope conclusions based on the draft once the final version is published. In its March 2026 draft guidance on applying the CRA, the EC does make some clarifications for the definition of “commercial activity” and addresses other key issues regarding scope.

Key clarifications include:


• A product can be free and open-source and still be considered “made available on the market” if it is also offered as part of a commercial service or monetized support model
• The presence of publicly available code alone, such as a GitHub repository, does not constitute market placement; a commercial relationship is what imposes responsibility
• Dual-license models (free OSS edition + commercial enterprise edition) place the commercial edition firmly within scope of the CRA; the free edition’s status further depends on its association with commercial activity
• Responsibility follows governance: whoever publishes and effectively controls a project bears the obligations, not whoever technically publishes changes to the software’s source code
• Manufacturer responsibility also extends beyond the original developer to companies integrating or rebranding OSS components into products placed on the EU market

September Reporting: The Clock Is Ticking

The first hard CRA deadline applies to all products with digital elements, including OSS. From 11 September 2026, manufacturers and stewards must report actively exploited vulnerabilities and severe incidents that may affect the security of the digital products they are responsible for.

The reporting deadlines are tight: an early warning is due within 24 hours of awareness, a full notification within 72 hours, and a final report within 14 days for exploited vulnerabilities or one month for severe incidents. Reports are submitted through ENISA’s Single Reporting Platform (SRP), and onboarding instructions and a reporting manual are expected from ENISA in June 2026.

What This Means for Greenbone

Greenbone operates across two tiers: as a manufacturer of digital products, and as an open-source software steward. As discussed above, the CRA imposes distinct obligations for both of these roles. As a manufacturer, Greenbone is responsible for the commercialized OPENVAS enterprise IT security products, and, as a steward, we take responsibility for our FOSS community projects.

Greenbone meets our manufacturer responsibilities through a wide range of IT security policies, controls, and response plans. This includes continuous vulnerability management, GDPR-compliant architecture, documented security practices, and other IT security best practices. As an active ISO/IEC 27001:2022 and ISO 9001:2015 certified organization, Greenbone is dedicated to the most stringent quality standards for Information Security. As an OSS steward, Greenbone is prepared to fulfill the CRA requirements for our OPENVAS community software projects.

Finally, as a vendor of digital products specifically for cyber security, Greenbone’s customers use our OPENVAS line of IT security products to meet their own CRA obligations. This means we are responsible not only for fulfilling our own CRA obligations, but also for understanding the technical needs that other organizations have to stay compliant. This dual role as a manufacturer of digital products and a vendor of cyber security products that help other organizations achieve CRA compliance gives Greenbone a clear vantage point: navigating the regulation while also broadly supporting global manufacturers of digital products to do the same.

Recommendations for Software Vendors Working with Open Source

1. Map your OSS usage. Every open-source component in your products must be identified, documented, and tracked. This is the foundation of your SBOM and is required by the CRA regardless of the component’s own compliance status.
2. Audit your commercial relationships. If you monetize OSS in any way, such as paid support, SaaS delivery, professional services, seek legal advice on whether full manufacturer obligations apply. The draft guidance’s monetization test is the place to start.
3. Prepare for September reporting now. Set up an internal process that can produce a 24-hour early warning, and watch for ENISA’s SRP onboarding instructions (due in June 2026).
4. Engage with the community. The ORC Working Group maintains a CRA FAQ and resource hub for OSS stewards and manufacturers (cra.orcwg.org and the CRA Hub on GitHub). The OpenSSF is also tracking CRA policy developments.
5. Track the EC’s final guidance. The feedback window closed on 31 March 2026. When the Commission publishes the final version, revisit any scope conclusions based on the draft.

Read the full guide: The Complete Guide to the EU Cyber Resilience Act – all requirements, timelines, and penalties in one place.



1. Sources European Commission — Cyber Resilience Act (Regulation EU 2024/2847), Official Journal https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
2. European Commission — CRA and open source software policy page
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
3. European Commission — Draft guidance announcement (3 March 2026)
https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act
4. European Commission — CRA reporting obligations
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
5. ENISA — Single Reporting Platform (SRP)
https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
6. Eclipse Foundation ORC Working Group — orcwg.org
https://orcwg.org/
7. ORC Working Group — CRA Hub (FAQ and implementation resources)
https://github.com/orcwg/cra-hub
8. ORC Working Group — White paper: Open Source Software Stewards and the CRA
https://orcwg.org/cra/resources/d3-5-white-paper-on-open-source-software-stewards-and-cra/
9. OpenSSF — EU Cyber Resilience Act policy page
https://openssf.org/public-policy/eu-cyber-resilience-act/
10. OpenSSF — Global Cyber Policy Working Group CRA tracker
https://policy.openssf.org/CRA/

Most companies treating the CRA as a 2027 problem are already behind. According to the 2026 CRA Awareness and Readiness Report from OpenSSF and Linux Foundation Research, 66% of software producers surveyed remain unfamiliar with the regulation — and that figure has risen year-over-year. The first enforcement date is not December 2027. It is 11 September 2026, when Article 14 vulnerability reporting obligations become legally binding. From that date, if a vulnerability in your product is being actively exploited, you are required to file an early warning through the ENISA Single Reporting Platform within 24 hours of becoming aware of it. Miss that window, and you are already non-compliant — with penalty exposure of up to €15 million or 2.5% of global annual turnover, whichever is higher.

What Exactly Must You Start Doing in September 2026?

The reporting obligation is triggered by two conditions, either of which requires action:

• An actively exploited vulnerability in any of your in-scope products, regardless of severity
• A severe incident affecting the security of your products — for example, a significant breach or systemic compromise

Once either condition is met, a three-stage reporting cascade begins:

Stage 1 — Early Warning: Within 24 Hours

Submit an early warning through the ENISA Single Reporting Platform confirming your awareness of an actively exploited vulnerability. You are not required to provide full technical details at this stage. The purpose is to flag that you are aware and managing the situation. The SRP will automatically route the report to your national CSIRT coordinator and to ENISA simultaneously.

Stage 2 — Full Notification: Within 72 Hours

Submit a full notification including technical details of the vulnerability, an initial severity assessment (using CVSS or equivalent), affected products and versions, and any available mitigations or workarounds. This report must be accurate and complete — rushed or inaccurate reports can trigger Tier 3 penalties for providing incorrect information.

Stage 3 — Final Report: Within 14 Days of Issuing a Fix

Once you have issued a security update or workaround, submit a final report to ENISA within 14 days, or one month in the case of a severe incident. This closes the reporting loop and must include a comprehensive vulnerability description, root cause analysis, impact assessment, and a full account of the remediation steps taken.

One Detail Most Teams Miss: It Applies to Existing Products Too

The September 2026 reporting obligations not only apply to products launched after that date. Under CRA Article 69(3), they apply to all products with digital elements already placed on the EU market, including products shipped years before the CRA existed. If a vulnerability in a product you released in 2021 is being actively exploited in September 2026, you are required to report it. This catches many teams off guard: your scope for this obligation is your entire active product catalogue, not just your next release.

A second detail worth locking in: the 24-hour clock starts at reasonable belief of active exploitation, not confirmed forensic evidence. If your monitoring flags credible signals of exploitation, you cannot wait for certainty before submitting the early warning. Waiting for confirmation is how organisations will miss the window.

Why This Is Harder Than It Sounds

Most organisations do not have a tested, 24-hour vulnerability notification process. Building one requires:

The Other Deadlines in the Frame

September 2026 is the most urgent date, but it is not the only one. By 30 August 2026, harmonised standards covering vulnerability handling (Type A/horizontal) and product security (Type B) are expected to be published — giving manufacturers their first authoritative compliance benchmarks. Full product conformity for all categories does not apply until 11 December 2027, but organisations that wait for the standards before starting work will have very little implementation runway.

This means that with less than 100 days until the reporting deadline and the harmonised standards landing just two weeks before it, the summer of 2026 is a period of compressed, parallel compliance activity. Starting this journey now is not early. It is the last moment to avoid being caught without a tested process when the clock starts.

Sources

1. Regulation (EU) 2024/2847 — Cyber Resilience Act (EUR-Lex, official legislative text)
   https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20

2. 2026 CRA Awareness and Readiness Report — OpenSSF / Linux Foundation Research
   https://openssf.org/blog/2026/05/18/taking-stock-of-the-state-of-european-cyber-resilience-act-cra-compliance-an-urgent-wake-up-call-for-the-open-source-ecosystem/

3. Cyber Resilience Act — Summary of the legislative text (European Commission)
   https://digital-strategy.ec.europa.eu/en/policies/cra-summary

4. Cyber Resilience Act — ENISA (Single Reporting Platform)
   https://www.enisa.europa.eu/topics/cyber-resilience-act

For nearly two decades, stolen credentials have been the focus of many analyses of security breaches. This picture is now changing. According to the Verizon 2026 Data Breach Investigations Report (DBIR), vulnerability exploitation has overtaken credential abuse as the top breach vector for the first time — accounting for 31% of breaches, compared to just 13% for credential theft. AI is accelerating attack development, compressing the window between vulnerability disclosure and exploitation from months to hours. ([Heise][1])

This shift is strategically significant. It means that companies can no longer rely solely on identity protection, phishing training, MFA, endpoint protection, or perimeter defense. While these controls remain essential, they do not address the central question that attackers are increasingly exploiting: Where is the company currently technically vulnerable?

Exploited > Stolen

AI is changing the pace of attacks

Generative AI and automation reduce the cost of reconnaissance, accelerate the development of exploits, and make it easier for attackers to scale their operations. The practical implication is clear: defenders must shorten the time between the disclosure, detection, prioritization, and remediation of vulnerabilities. In an environment where attackers can identify and exploit exposed vulnerabilities more quickly, vulnerability management is no longer just a periodic compliance measure. It is becoming an operational security discipline.

Vulnerability management closes the gap

Organizations must identify vulnerabilities before attackers exploit them. We view vulnerability management as the central process in which vulnerabilities in the IT infrastructure are uncovered, classified by severity, and remediation measures are recommended. This allows vulnerabilities to be eliminated before they become exploitable risks.

Vulnerability management examines the infrastructure from the attacker’s perspective and asks which systems, services, devices, and configurations are currently exposed. Greenbone explicitly positions this “outside-in” perspective as a complement to firewalls and other defense systems.

Why OpenVAS is the right vulnerability scanner right now

OPENVAS is our answer to this problem. We offer authenticated and unauthenticated testing, support for internet and industrial protocols, optimization of large-scale scans, and a powerful internal language for vulnerability testing. Our tests are sourced from a feed with daily updates, and have been since 2006.

Our enterprise vulnerability management solutions utilize more than 225,000 vulnerability tests, with new tests added daily. This is important because vulnerability management is only effective if it reflects the current threat landscape. A scanner that isn’t continuously updated will quickly be outpaced by attackers.

The economic case has become more compelling

AI is changing the economic case for vulnerability management. The need is not abstract. It is driven by measurable changes in attacker behavior. The 2026 DBIR found that the median time to full patching grew to 43 days (up from 32 days the year before) while organizations patched only 26% of vulnerabilities in CISA’s Known Exploited Vulnerabilities (KEV) catalog, down from 38% in 2024.

When exploited vulnerabilities become the primary entry point into organizations, identifying and reducing the attack surface is one of the most effective ways to lower the likelihood of security breaches.

Conclusion: Security teams need continuous visibility

The lesson from the latest attack data is simple: organizations must assume that their disclosed vulnerabilities will be discovered, correlated, and exploited faster than ever before. Protecting login credentials remains essential, but it is no longer sufficient. The new priority lies in continuous visibility into the attack surface, risk-based prioritization, and rapid remediation.

This is exactly where Greenbone and OPENVAS come into play. In a threat landscape where attackers are increasingly exploiting known and detectable vulnerabilities, vulnerability management becomes the first line of defense: identify the vulnerability, understand the risk, and act before the attacker does.

[1]: https://www.heise.de/news/KI-Aera-Laut-Verizon-mehr-Angriffe-ueber-Luecken-als-mit-gestohlenen-Zugangsdaten-11299991.html?utm_source=chatgpt.com “AI Era: According to Verizon, More Attacks via Vulnerabilities Than with Stolen Credentials”

[2]: https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/?utm_source=chatgpt.com “Verizon DBIR 2026: Exploitation of vulnerabilities overtakes credential theft as the most common attack method”

[3]: https://www.verizon.com/business/resources/reports/dbir/ “2026 Data Breach Investigations Report (DBIR) | Verizon”

[4]: https://www.greenbone.net/en/ “Vulnerability Management | Open Source and GDPR-Compliant”

Defenders deploying Fedora will be pleased to know that Greenbone’s OPENVAS SCAN now includes detection for Fedora 44 security advisories via the OPENVAS ENTERPRISE FEED and COMMUNITY FEED. Fedora Linux 44 was released on April 28th, 2026, and releases are typically maintained for 13 months. Fedora 44 has been assigned an expected end-of-life (EOL) date of May 19th, 2027. Support for Fedora 44 extends OPENVAS SCAN’s existing detection capabilities for Fedora security advisories going back to Fedora 7.

Greenbone’s OPENVAS SCAN has industry-leading detection for popular Linux distributions via authenticated Local Security Checks (LSC). Authenticated LSCs provide reliable detection because they analyze endpoint systems from within, build an asset inventory, uncover package-level software vulnerabilities, and identify other security misconfigurations.

Defenders seeking to detect and protect can try Greenbone’s OPENVAS BASIC for free, including a two-week trial of the OPENVAS ENTERPRISE FEED.

Fedora 44 Support

Operating system (OS) security updates are critical for maintaining a strong enterprise security posture. A single flaw may give an attacker the initial access needed to execute a costly cyber attack. OS vulnerabilities impact all aspects of IT infrastructure, including on-premises and cloud assets, fleets of staff workstations, development environments, container hosts, virtualization platforms, and edge infrastructure. New regulations and compliance requirements are also demanding greater accountability and placing heavier burdens on IT security teams. Defenders need improved visibility into emerging security risks to effectively prioritize remediation.

Support for Fedora 44 Security Advisories Is Here!

Fedora security advisories are published through the Fedora Updates System, also known as Bodhi. Each advisory includes a unique advisory identifier, affected package builds, update status, a list of associated CVEs, an overall severity rating, and testing status for the patch.

Organizations deploying Fedora 44 will be excited to know that Greenbone’s OPENVAS SCAN now supports vulnerability detection for Fedora 44 security advisories in both the OPENVAS ENTERPRISE FEED and the COMMUNITY FEED.

• Visit the official site for Fedora security updates
• View all OPENVAS SCAN vulnerability tests for Fedora 44

Summary

Linux systems form the backbone of many enterprise environments, supporting critical infrastructure, cloud platforms, staff workstations, development systems, container hosts, and production workloads. Maintaining Linux security requires consistent visibility into vulnerabilities and timely patch management. Effective OS-level vulnerability management reduces exposure to exploitation, supports regulatory compliance, and helps organizations maintain a resilient security posture.

Organizations deploying Fedora Linux can now use Greenbone’s OPENVAS SCAN to detect Fedora 44 security advisories via the OPENVAS ENTERPRISE FEED and COMMUNITY FEED. This adds security visibility for a newly released Fedora platform and helps defenders identify missing security updates across Fedora systems using authenticated package-level detection.

Fedora 44 support joins other popular Linux operating systems supported in both the OPENVAS ENTERPRISE FEED and COMMUNITY FEED, including Ubuntu, Debian, Suse, OpenSuse, Huawei EulerOS, OpenEuler, and Mageia. Greenbone’s OPENVAS ENTERPRISE FEED supports additional Linux distributions, including Amazon Linux, Oracle Linux, AlmaLinux OS, FortiOS, and many more.

Defenders can try Greenbone’s OPENVAS BASIC for free, including a two-week trial of the OPENVAS ENTERPRISE FEED.

In April 2026, the cyber security landscape was flooded with news about Anthropic’s new Mythos bug-hunting AI and Project Glasswing. The rose-colored takeaway is that one year from now, software will be free from vulnerabilities because AI will find all of the flaws and vendors will patch. Major software companies will scan all their products pre-release and software vulnerabilities will be a thing of the past. However, reality likely has something else in store. Let’s dig into the evolving cyber risk landscape of April 2026.

April 2026 Threat Report

Although several of this month’s top threats are mentioned here, many emerging vulnerabilities are not. OPENVAS SCAN doesn’t just detect the most critical flaws in your IT environment. Greenbone’s OPENVAS ENTERPRISE FEED adds thousands of new vulnerability tests per month to detect flaws in enterprise software applications, IT networking products, major OSs and browsers, Linux packages, productivity tools, agentic AI tooling, and more. Defenders seeking to detect and protect can try Greenbone’s entry-level OPENVAS BASIC for free, including a two-week trial of the ENTERPRISE FEED.

Mythos or Reality? Time to Find Out

Project Glasswing created a media frenzy, yet transparency remained elusive. Anthropic did not release a public list matching its claim of “thousands of zero-day vulnerabilities” across “every major operating system” and “every major web browser”. This month, VulnCheck found only 75 published CVE records mentioning “Anthropic” and only 40 of those were credited to Anthropic researchers. So far, only one CVE is explicitly attributed to Project Glasswing: CVE-2026-4747 (CVSS 8.8).

The potential risk posed by offensive AI technology is high. The immediate advice from established cyber security authorities SANS Institute and the Cloud Security Alliance (CSA) is for organizations to double down on core cybersecurity measures. Ensure strong mitigating and preventative controls such as the principle of least privilege (PoLP), network segmentation to prevent lateral movement, patch faster, and be prepared for a possible influx of new high-severity CVEs. Also, where potential zero-day exploitation creates high risk, outfit endpoints with detection and response technologies, and be prepared to redeploy critical assets with minimal downtime. Third-party risk can also directly impact your organization’s operations. This is a more balanced interpretation of the near-term risk that organizations face.

Apache ActiveMQ Actively Exploited for RCE

CVE-2026-34197 (CVSS 8.8, EPSS ≥ 98th pctl) is a code injection flaw caused by improper input validation affecting Apache ActiveMQ Classic. Apache ActiveMQ is a popular Java-based message broker that handles asynchronous communication via message queues with support for flexible client options. CVE-2026-34197 has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog and multiple national CERT agencies have issued alerts globally [1][2][3][4][5][6][7][8]. Previous flaws in ActiveMQ are known to be leveraged in ransomware attacks. A full technical description and proof-of-concept (PoC) exploit kit are publicly available increasing the risk. Shadowserver reports roughly 8,000 exposed instances of ActiveMQ on the Internet.

The new CVE is considered a bypass of CVE-2022-41678 (CVSS 8.8). Exploiting CVE-2026-34197 does not require credentials on ActiveMQ v6.0.0–6.1.1 due to another unpatched missing authentication vulnerability, CVE-2024-32114 (CVSS 8.8). While authentication is required for exploiting other versions of ActiveMQ, default credentials are also a factor for unauthorized access. Incidentally, the Horizon3.ai security researcher who discovered CVE-2026-34197 attributed 80% of the process to a pre-Mythos version of Claude AI.

Greenbone’s OPENVAS ENTERPRISE FEED includes an active check and a remote banner version check for CVE-2026-34197. Users must upgrade to v5.19.4 or v6.2.3 for mitigation.

Trojan Documents Exploiting Adobe Acrobat and Reader

CVE-2026-34621 (CVSS 8.6, EPSS ≥ 92nd pctl) is a prototype pollution flaw [CWE-1321] that allows arbitrary code execution in the context of the current user. CVE-2026-34621 is exploitable via social engineering and requires a malicious PDF file to be opened. CVE-2026-34621 has been added to CISA’s KEV list and Adobe acknowledged active exploitation in a security bulletin. Numerous national CERT alerts have been issued globally [1][2][3][4][5][6][7][8][9][10][11][12][13][14].

According to security researchers, the flaw has been exploited since at least late 2025 as indicated by VirusTotal findings. The identified malware base64-decodes a payload and executes it as JavaScript to extract information from the victim’s computer, including the contents of local files, sends the data to the attacker’s command-and-control (C2) server, and awaits further instructions to execute. Another malware analysis report found that malware exploiting CVE-2026-34621 abuses multiple undocumented internal APIs in Adobe Acrobat and Reader in the attack chain.

Affected products are Acrobat DC Continuous 26.001.21367 and earlier, Acrobat Reader DC Continuous 26.001.21367 and earlier, and Acrobat 2024 Classic 2024 24.001.30356 and earlier on Windows and macOS. The OPENVAS ENTERPRISE FEED includes detection tests for all affected products on Windows [15][16][17] and macOS [18][19][20]. Users should update to a patched version immediately.

CVE-2026-3854: Authenticated RCE in Git Enterprise and GitHub.com

CVE-2026-3854 (CVSS 8.8) allows an authenticated attacker with push permissions to a repository to achieve RCE on a Git server. During a git push operation, user-supplied values are not properly sanitized before being included in internal service headers, potentially resulting in command injection [CWE-77] and RCE.

Several Git products including GitHub.com, GitHub Enterprise Server, and GitHub Enterprise Cloud are affected. A full technical description has been published and public PoC exploits have been sighted by CIRCL.lu. Although GitHub.com’s public infrastructure was affected, internal forensic review found no evidence of in-the-wild exploitation or indicators of compromise (IoC).

The OPENVAS ENTERPRISE FEED includes package-level detection for GitHub Enterprise Server. Users should upgrade to GitHub Enterprise Server versions 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, or 3.19.4.

Patch Now! High-Severity Flaws in Core Linux Components

Let’s turn our focus to Greenbone’s support for Linux security advisories and what the OPENVAS ENTERPRISE FEED can do for security teams managing Linux assets by reviewing some of the top Linux flaws from April 2026.

Pack2TheRoot: Linux Privilege Escalation via Linux PackageKit

PackageKit is the D-Bus system-level API for managing software packages across different Linux package managers, including APT, DNF, RPM, and Pacman. CVE-2026-41651 (CVSS 8.8), dubbed Pack2TheRoot, is an attack chain that combines three separate bugs into an exploitable time-of-check-time-of-use (TOCTOU) race condition [CWE-367]. The flaw ultimately allows unprivileged users to install arbitrary packages as root.

Telekom Security published a technical description, including a detailed PoC exploit. Other PoC exploits can also be found online [1][2] and several national CERT alerts have been issued globally [1][2][3]. The OPENVAS ENTERPRISE FEED includes detection for CVE-2026-41651 as reported in Linux security advisories. PackageKit versions 1.0.2 through 1.3.4 are affected and users should update to version 1.3.5.

CVE-2026-33413: Authentication Bypass in etcd

etcd is a distributed key-value store designed for authoritative data coordination in Linux environments. CVE-2026-33413 (CVSS 8.8) is a missing authorization vulnerability [CWE-862] in etcd clusters with auth enabled. The flaw allows attackers to access sensitive etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients. RCE is not described as a potential impact of CVE-2026-33413. However, an attacker may learn cluster topology, including member IDs and advertised endpoints, permanently remove historical revisions, disrupt watch, audit, and recovery workflows, or trigger denial of service (DoS) conditions.

etcd is often associated with Kubernetes, where it stores the cluster’s authoritative state, including nodes, pods, secrets, and control-plane metadata. However, since Kubernetes does not rely on etcd’s built-in authentication and authorization, typical Kubernetes deployments are not affected.

Germany [1] and France [2] have issued national CERT advisories for the flaw. Greenbone includes remote banner version check for detecting exposed etcd services affected by CVE-2026-33413. etcd versions 3.4.42, 3.5.28, and 3.6.9 contain a patch for CVE-2026-33413.

CVE-2026-34714: Trojan Vim Files Can Execute Arbitrary Code

CVE-2026-34714 (CVSS 8.6) allows arbitrary OS commands to be executed when a user opens a specially crafted file. These commands are executed with the privileges of the user who opened the file. CVE-2026-34714 is classified as a command injection flaw caused by improper neutralization of special elements [CWE-78].

There is no public PoC exploit for CVE-2026-34714, and it is not considered exploited in the wild. The OPENVAS ENTERPRISE FEED includes detection for CVE-2026-34714 as reported in Linux security advisories. The flaw was introduced in v9.1.1390 and patched in v9.2.0172.

CVE-2026-34078: Sandbox Escape and RCE via Malicious Flatpak Apps

CVE-2026-34078 (CVSS 10) is a complete sandbox escape of the flatpak run process caused by an exploitable TOCTOU race condition [CWE-367] when file paths provided as sandbox-expose options are replaced with symlinks post-verification. Once flatpak run mounts the swapped-out symlink in the sandbox, a malicious app can read and write arbitrary files on the host and exploit these unauthorized privileges to gain code execution.

There is no public PoC exploit for CVE-2026-34078, and it is not considered exploited in the wild. The OPENVAS ENTERPRISE FEED includes detection for CVE-2026-34078 as reported in Linux security advisories. Users should upgrade to Flatpak version 1.16.4 for mitigation.

Microsoft Risk: New Active Exploitation and Disclosure Controversy

A large Patch Tuesday included 173 new vulnerabilities in Microsoft’s core products. Nineteen were rated as “Exploitation More Likely”, and two were quickly added to CISA’s KEV list. Another critical flaw, CVE-2026-40372 (CVSS 9.1), was disclosed out-of-band. Also, a disgruntled security researcher abandoned the responsible disclosure process with Microsoft and published PoC exploit code for an otherwise undisclosed and unpatched vulnerability.

Let’s review some of these new high-risk Microsoft vulnerabilities:

• CVE-2026-33825 (CVSS 7.8, EPSS ≥ 87th pctl): A local privilege escalation (LPE) in Microsoft Defender allows a local user to gain SYSTEM-level permissions. Dubbed “BlueHammer”, the flaw was reportedly disclosed by a disgruntled security researcher, along with a PoC exploit. Technical analyses have also been published [1][2]. BlueHammer is exploited in the wild and has been added to CISA’s KEV list. Two additional zero-days disclosed by the disgruntled researcher, dubbed RedSun and UnDefend, remain unpatched by Microsoft despite having PoC exploits [3][4] and being observed in active attacks.
• CVE-2026-32201 (CVSS 6.5): A new actively exploited flaw in Microsoft SharePoint Server caused by improper input validation [CWE-20] allows an unauthorized attacker to perform spoofing over a network. Technical details about CVE-2026-32201 are not publicly available, and no public PoC exploit exists. Previous SharePoint flaws have been targeted by sophisticated nation-state threat actors [5][6][7]. CVE-2026-32201 comes soon after another SharePoint vulnerability, CVE-2026-20963 (CVSS 9.8, EPSS ≥ 90th pctl), was added to CISA’s KEV in April 2026.
• CVE-2026-32202 (CVSS 4.3, EPSS ≥ 92nd pctl): A protection mechanism failure [CWE-693] in Windows Shell allows an unauthorized attacker to remotely bypass Microsoft Defender security controls. The flaw has been added to CISA’s KEV list. A detailed technical report from Akamai shows that CVE-2026-32202 is an incomplete patch for CVE-2026-21510 (CVSS 8.8), which was actively exploited by APT-28.
• CVE-2026-40372 (CVSS 9.1): Changes introduced in version 10.0.6 of the AspNetCore.DataProtection package in .NET Core caused secret decryption failure for some users [8][9]. Following investigation, Microsoft determined that the update also allows unauthorized attackers to elevate privileges over a network. Technical details about CVE-2026-40372 are not publicly available, and no public PoC exploit exists. Versions 10.0.0 – 10.0.6 are affected by CVE-2026-40372 and users should update .NET Core runtime to version 10.0.7 and .NET Core SDK to version 10.0.107 or 10.0.203.

Greenbone’s OPENVAS ENTERPRISE FEED includes detection for all Microsoft CVEs referenced above and frequently updated dedicated families of detection tests for Microsoft products.

CVE-2026-2699: Unauthenticated RCE in Progress ShareFile with Public PoC

CVE-2026-2699 (CVSS 9.8, EPSS ≥ 96th pctl) allows unauthenticated read and write access to restricted configuration pages on Progress ShareFile Storage Controller. The flaw allows changing system configurations and potentially, unauthenticated RCE. CVE-2026-2701 (CVSS 8.8, EPSS ≥ 70th pctl) has a similar impact for authenticated users; an authenticated attacker can upload a malicious file and execute it, leading to RCE.

Progress Software’s products have frequently been targeted in ransomware attacks in the past [1][2][3][4]. Although neither CVE is considered actively exploited yet, watchTowr Labs released a full technical write-up covering both CVEs that includes PoC exploit code. ShadowServer data indicates that the majority of publicly exposed instances are concentrated in the United States. Italy [5] and France [6] have issued CERT alerts for the pair of new CVEs.

The OPENVAS ENTERPRISE FEED includes a remote exploitability check for CVE-2026-2699 and a remote banner version check that covers both CVE-2026-2699 and CVE-2026-2701. All versions of Progress ShareFile StorageZones Controller before 5.12.4 are affected.

CVE-2025-59528: Actively Exploited CVSS 10 Flaw in Flowise

CVE-2025-59528 (CVSS 10, EPSS ≥ 99th pctl) is a code injection flaw [CWE-94] affecting Flowise prior to version 3.0.6. User-defined configuration settings from the CustomMCP node are passed directly to the Function() constructor, which executes JavaScript expressions without security validation. CustomMCP runs with Node.js runtime privileges and has access to dangerous modules such as child_process and fs.

CVE-2025-59528 was disclosed in September 2025, but the flaw gained more attention [1][2][3] this month, when it was reported as actively exploited. Notably, PoC exploit code was revealed by the vendor at disclosure time. The OPENVAS ENTERPRISE FEED has included a remote banner version check for CVE-2025-59528 since it was published, along with numerous tests for other Flowise CVEs, and a product detection module for Flowise. Users should upgrade to version 3.0.6.

Authenticated Command Execution on Juniper Networks MX Series Devices

CVE-2026-33785 (CVSS 8.8) allows a local, authenticated user with low privileges to execute dangerous commands on the CLI on Juniper Networks Junos OS on MX Series. Exploitation could lead to complete system compromise of managed devices. The root cause is missing authorization [CWE-862] for request csds operations, which are only meant to be executed by high-privileged users.

CVE-2026-33785 is not considered actively exploited and PoC exploit code is not publicly available. The OPENVAS ENTERPRISE FEED includes a remote banner version check for CVE-2026-33785, and detection for many other flaws in Juniper Networks products. CVE-2026-33785 affects Junos OS on MX Series, 24.4 releases before 24.4R2-S3 and 25.2 releases before 25.2R2. This issue does not affect Junos OS releases before 24.4.

TrueChaos: Campaign Targeting TrueConf Client in Southeast Asia

CVE-2026-3502 (CVSS 7.8, EPSS ≥ 85th pctl) allows an attacker who can influence the update delivery path to TrueConf Client applications to inject and execute a tampered update payload. TrueConf is a video conferencing and unified communications product family often deployed on-premises in private networks for secure, sovereign communication.

CVE-2026-3502 was added to CISA’s KEV list and Check Point has published details on at least one attack campaign dubbed “TrueChaos” targeting the government agencies of an unnamed Southeast Asian country. The malicious update still upgraded the victim’s client from 8.5.1 to 8.5.2 to reduce suspicion.

Greenbone’s OPENVAS ENTERPRISE FEED includes an authenticated registry check to identify vulnerable installations of TrueConf Client. All versions prior to 8.5.3.884 are affected and users should upgrade TrueConf Client to version 8.5.3.884 or later.

Summary

AI-assisted vulnerability discovery has accelerated the sheer number of CVEs published each month. The increase reflects a combination of both AI-slop and legitimate critical-severity flaws in widely popular enterprise software. Anthropic’s Mythos could result in more high-impact disclosures, but so far evidence has been elusive. The SANS institute and CSA have advised organizations to essentially double their efforts towards core cyber security controls.

Defenders should employ continuous vulnerability management programs to reduce risk exposure with OPENVAS SCAN and the OPENVAS ENTERPRISE FEED for industry-leading vulnerability coverage. Greenbone produces thousands of new vulnerability tests per month to detect flaws in enterprise software applications, IT networking products, major OSs and browsers, Linux packages, productivity tools, agentic AI tooling, and more. Defenders seeking to detect and protect can try Greenbone’s entry-level OPENVAS BASIC for free, including a two-week trial of the ENTERPRISE FEED.