CVE-2026-40356 is a denial-of-service vulnerability in MIT Kerberos 5 before version 1.22.3, disclosed in April 2026, affecting applications that call
The vulnerable code path is narrow. An application must accept a GSS-API security context, the host must have a NegoEx mechanism registered, and the malformed token must reach the parsing logic. That combination keeps the score out of “drop everything everywhere” territory, but it also means the affected systems are likely to be the ones doing real authentication work rather than idle lab machines.
MIT’s fix describes the issue as a NegoEx parsing problem: a short header length can cause an integer underflow while calculating the remaining message length. The related commit also notes a read overrun of up to 52 bytes and says exfiltration of the bytes read does not appear possible. In other words, this is not being presented as a clean information disclosure primitive; it is a crash bug in a security-sensitive parser.
That distinction matters because administrators tend to prioritize authentication vulnerabilities by the wrong instinct. Remote code execution and credential exposure get emergency meetings. Denial of service gets routed into normal patch management unless somebody can name the business process that stops when the authentication gateway dies.
CVE-2026-40356 is exactly the kind of bug that punishes that habit. If the exposed process is a web front end using Kerberos-backed SSO, a storage service using GSSAPI, or a proxy sitting in front of internal applications, repeated unauthenticated crashes can become a user-visible outage without ever becoming a domain compromise.
The vulnerable scenario requires a NegoEx mechanism registered in
The uncomfortable part is that these are rarely the cleanest machines in the fleet. Authentication bridges, appliances, reverse proxies, NFS servers, Samba-adjacent hosts, and custom line-of-business services often accumulate configuration over years. A mechanism entry added to solve one integration problem can remain long after the original engineer has moved on.
That is why the phrase “registered in
It does, however, mean Microsoft considered the issue relevant enough to surface to its customers. That makes sense in 2026. Microsoft identity environments are no longer just domain controllers, joined Windows desktops, and a few file servers. They are hybrid estates with Linux workloads, containers, third-party appliances, cloud-hosted services, and identity-aware middleware all trying to speak enough Kerberos to keep single sign-on working.
For Windows administrators, the operational question is therefore not “Is my domain controller affected?” The better question is “Which non-Windows services in my Microsoft identity environment accept GSS-API contexts using MIT krb5?” That list may include systems owned by Unix teams, application teams, storage teams, or vendors who package krb5 inside their product.
This is where vulnerability management often falls down. The Windows team may see the MSRC entry and assume Linux owns the patch. The Linux team may see Kerberos and assume identity owns the risk. The identity team may see MIT krb5 and assume it is outside Active Directory. Meanwhile, the exposed service continues accepting unauthenticated negotiation tokens.
Attack complexity is rated high because the vulnerable path depends on configuration and protocol conditions. But once an attacker can reliably hit a susceptible service, the payload does not need to steal a password to cause damage. Authentication-facing services are often choke points, and choke points convert process termination into business interruption.
There is a difference between “the process might terminate” and “the company is offline,” of course. A service supervisor may restart the process. Load balancing may shift traffic. Rate limits may slow repeated attempts. A well-designed service may isolate the crash to a worker process rather than the whole daemon.
But availability bugs should be judged by the role of the component, not only the elegance of the exploit. If the vulnerable process is part of login, ticket validation, SSO, storage access, or remote application entry, the attacker does not need permanence. A repeated crash loop during business hours is enough to create a security incident, a help desk surge, and a very long afternoon.
The fix is correspondingly modest. The code now checks for a short
That smallness is not a reason to minimize the bug. It is a reason to respect how much authority these libraries carry. MIT krb5 is a mature, widely deployed component precisely because it has spent decades disappearing into the background. Mature does not mean frozen; it means the code is asked to operate correctly in more deployment shapes than any one maintainer can reasonably simulate.
The most useful lesson here is not “C is unsafe,” although C certainly makes this class of failure easier to create. The lesson is that protocol negotiation code deserves the same suspicion as cryptographic code. It is reachable before authentication succeeds, it consumes attacker-controlled structure, and it often runs inside processes administrators cannot casually restart without consequences.
That is especially common in Linux-heavy estates that still use AD as the account source. A Linux web application might use GSSAPI for integrated authentication. A file service might accept Kerberos-authenticated access. A proxy might front internal resources and translate authentication state across platforms. The user sees “Sign in with Windows credentials,” while the server-side implementation is a patchwork of libraries, PAM modules, service principals, keytabs, and mechanism configuration.
This is why the advisory deserves attention from Windows admins even if it does not demand emergency domain controller patching. The practical exposure follows trust relationships, not branding. If a service participates in the same identity fabric users depend on, a crash in that service is still a Windows environment problem from the user’s point of view.
It also lands during a period when Microsoft has been tightening Kerberos defaults and pushing organizations away from weaker legacy behavior such as RC4 dependence. That broader hardening work is separate from CVE-2026-40356, but it creates the same operational mood: old Kerberos assumptions are being reexamined, and cross-platform authentication dependencies are no longer safe to leave undocumented.
The better first pass is service-oriented. Which systems accept inbound GSS-API security contexts? Which ones expose Kerberos-capable authentication over the network? Which ones have NegoEx configured in
This distinction matters because enterprise patching is a scheduling problem as much as a technical one. If a vulnerable library is present on a build host with no exposed GSS-API accepting service, it still needs updating, but it probably does not outrank an internet-facing or partner-facing authentication gateway. If a storage appliance or application server accepts Kerberos from a broad internal network, it may deserve expedited handling even with a medium score.
Administrators should also resist the temptation to remove mechanism entries blindly unless they understand the dependency. Disabling NegoEx may reduce exposure in some environments, but it can also break clients that rely on negotiation behavior. A controlled package update is usually the cleaner fix; configuration mitigation is for cases where patching is delayed and testing confirms the mechanism is unnecessary.
That last point is important. Credential attacks usually leave identity-shaped traces: failed logons, bad passwords, suspicious principals, unusual ticket requests. Parser-level denial of service may look more like infrastructure instability. Users report that single sign-on is flaky, a daemon restarts repeatedly, or a service becomes unreachable under load. The security signal is buried under availability noise.
Organizations with EDR or systemd journal aggregation should be able to correlate restarts with inbound authentication attempts. Those without centralized logs will have a harder time distinguishing attempted exploitation from ordinary fragility. That is one reason availability vulnerabilities are often under-investigated: they can be dismissed as operational gremlins until someone proves the crash is externally triggerable.
Rate limiting and network segmentation can help blunt repeated attempts, but they are not substitutes for fixing the parser. If the vulnerable service must accept Kerberos negotiation from a large internal population, an attacker who already has a foothold inside the network may not need much bandwidth to cause repeated pain.
For Debian, Ubuntu, Red Hat, SUSE, and other enterprise Linux ecosystems, the real question is the vendor advisory state and package changelog, not merely whether
This lag is where medium-severity bugs can linger. They may not trigger executive attention, but they remain reachable in the obscure systems that nobody rebuilds often: older middleware servers, lab-to-production “temporary” services, internal portals, monitoring gateways, and file services that have not been through a full dependency refresh in years.
The most disciplined organizations will treat this as a chance to test their identity-component inventory. If they cannot answer which services use MIT krb5 for GSS-API acceptance, the vulnerability has already revealed a process gap. The patch fixes the underflow; the inventory fixes the blind spot.
That makes negotiation-layer vulnerabilities disproportionately interesting. The attacker is not attacking the cryptographic heart of Kerberos or forging tickets. The attacker is abusing the code that tries to understand what kind of security conversation is about to happen. It is a reminder that authentication systems have edges, and those edges can fail before the system reaches the part administrators think of as “the Kerberos bit.”
NegoEx exists because environments need extensibility. Extensibility creates more states, more structures, and more opportunities for malformed input to surprise parsers. That is not an argument against NegoEx or against Kerberos interoperability. It is an argument for treating identity glue as attack surface rather than plumbing.
The industry has become better at hardening the obvious endpoints: domain controllers, identity providers, privileged access systems, and cloud control planes. The next layer of risk lives in the connective tissue. CVE-2026-40356 is not catastrophic by itself, but it points at that connective tissue with unusual clarity.
A sensible response begins by asking Unix, identity, application, and security teams the same question in the same meeting: where do we accept Kerberos or GSS-API authentication outside Windows Server? That conversation will surface systems that do not appear in a simple “Kerberos” dashboard. It may also reveal unsupported packages, stale containers, or vendor products whose authentication libraries are inherited rather than actively managed.
The next step is to verify NegoEx registration. The vulnerable condition depends on a NegoEx mechanism being registered in
Finally, administrators should patch with the seriousness they reserve for infrastructure dependencies. Authentication libraries are not convenience packages. When they fail, users do not experience “a library crash”; they experience inability to reach mail, files, dashboards, shells, repositories, or internal applications.
gss_accept_sec_context() on systems where a NegoEx mechanism is registered in /etc/gss/mech. That dry sentence hides the practical problem: this is not a glamorous credential-theft bug, but it sits in authentication plumbing many organizations treat as too foundational to touch casually. The attacker does not need an account, only network reachability and the right service exposure. For WindowsForum readers, the significance is not that Windows Kerberos itself has suddenly fallen over; it is that modern identity stacks are increasingly cross-platform, and a crash in the wrong Kerberos-facing process can look very much like an outage.
The Bug Is Small, but the Blast Radius Depends on Where Kerberos Lives
The vulnerable code path is narrow. An application must accept a GSS-API security context, the host must have a NegoEx mechanism registered, and the malformed token must reach the parsing logic. That combination keeps the score out of “drop everything everywhere” territory, but it also means the affected systems are likely to be the ones doing real authentication work rather than idle lab machines.MIT’s fix describes the issue as a NegoEx parsing problem: a short header length can cause an integer underflow while calculating the remaining message length. The related commit also notes a read overrun of up to 52 bytes and says exfiltration of the bytes read does not appear possible. In other words, this is not being presented as a clean information disclosure primitive; it is a crash bug in a security-sensitive parser.
That distinction matters because administrators tend to prioritize authentication vulnerabilities by the wrong instinct. Remote code execution and credential exposure get emergency meetings. Denial of service gets routed into normal patch management unless somebody can name the business process that stops when the authentication gateway dies.
CVE-2026-40356 is exactly the kind of bug that punishes that habit. If the exposed process is a web front end using Kerberos-backed SSO, a storage service using GSSAPI, or a proxy sitting in front of internal applications, repeated unauthenticated crashes can become a user-visible outage without ever becoming a domain compromise.
NegoEx Turns a Compatibility Feature Into a Security Boundary
NegoEx, short for SPNEGO Extended Negotiation, is one of those mechanisms most users never see but enterprise authentication stacks depend on to make heterogeneous systems behave as if they were designed together. It exists in the negotiation layer, where peers figure out which security mechanism they are going to use before the real work begins. That makes it attractive from an interoperability standpoint and unforgiving from a parser-safety standpoint.The vulnerable scenario requires a NegoEx mechanism registered in
/etc/gss/mech, which is a strong clue about where to look first. This is not a blanket indictment of every MIT krb5 installation on every Linux host. It is a warning about systems that have been configured to participate in this extended negotiation path, often because they sit near Windows identity infrastructure or need to interoperate with Active Directory-oriented clients.The uncomfortable part is that these are rarely the cleanest machines in the fleet. Authentication bridges, appliances, reverse proxies, NFS servers, Samba-adjacent hosts, and custom line-of-business services often accumulate configuration over years. A mechanism entry added to solve one integration problem can remain long after the original engineer has moved on.
That is why the phrase “registered in
/etc/gss/mech” should not lull anyone into thinking this is merely a local configuration footnote. In enterprise environments, configuration is architecture. If the file says the mechanism exists, network input may be able to steer execution into code that the organization forgot it had enabled.Microsoft’s Presence in the Advisory Is a Signal, Not a Windows Panic Button
The user-facing source here is Microsoft’s Security Update Guide, but the vulnerable component is MIT Kerberos 5, not the Windows Kerberos implementation built into domain controllers and clients. That is an important line to draw. A Microsoft advisory entry does not automatically mean Windows Server is vulnerable in the same way a Linux host running MIT krb5 is vulnerable.It does, however, mean Microsoft considered the issue relevant enough to surface to its customers. That makes sense in 2026. Microsoft identity environments are no longer just domain controllers, joined Windows desktops, and a few file servers. They are hybrid estates with Linux workloads, containers, third-party appliances, cloud-hosted services, and identity-aware middleware all trying to speak enough Kerberos to keep single sign-on working.
For Windows administrators, the operational question is therefore not “Is my domain controller affected?” The better question is “Which non-Windows services in my Microsoft identity environment accept GSS-API contexts using MIT krb5?” That list may include systems owned by Unix teams, application teams, storage teams, or vendors who package krb5 inside their product.
This is where vulnerability management often falls down. The Windows team may see the MSRC entry and assume Linux owns the patch. The Linux team may see Kerberos and assume identity owns the risk. The identity team may see MIT krb5 and assume it is outside Active Directory. Meanwhile, the exposed service continues accepting unauthenticated negotiation tokens.
A Medium Score Can Still Mean a Hard Outage
The published scoring puts CVE-2026-40356 in medium-severity territory, with network attack vector, no privileges required, no user interaction, no confidentiality impact, no integrity impact, and high availability impact. That is a perfectly reasonable mathematical outcome. It is also a reminder that CVSS is a severity model, not an incident priority model.Attack complexity is rated high because the vulnerable path depends on configuration and protocol conditions. But once an attacker can reliably hit a susceptible service, the payload does not need to steal a password to cause damage. Authentication-facing services are often choke points, and choke points convert process termination into business interruption.
There is a difference between “the process might terminate” and “the company is offline,” of course. A service supervisor may restart the process. Load balancing may shift traffic. Rate limits may slow repeated attempts. A well-designed service may isolate the crash to a worker process rather than the whole daemon.
But availability bugs should be judged by the role of the component, not only the elegance of the exploit. If the vulnerable process is part of login, ticket validation, SSO, storage access, or remote application entry, the attacker does not need permanence. A repeated crash loop during business hours is enough to create a security incident, a help desk surge, and a very long afternoon.
The Parser Failed Where Parsers Usually Fail
The underlying programming error is familiar: arithmetic on lengths, offsets, and remaining buffer sizes went wrong. In this case, the vulnerable path involves an integer underflow and an out-of-bounds read during NegoEx message parsing. That is old territory in security engineering, but old territory keeps producing new CVEs because parsers sit at the boundary between hostile input and trusted code.The fix is correspondingly modest. The code now checks for a short
header_len before subtracting values and calculating how much message remains. Another nearby NegoEx parsing flaw, tracked separately, adds a check before dereferencing the result of a vector calculation. Six added lines and one changed condition can be the difference between rejecting a defective token and reading past the intended buffer.That smallness is not a reason to minimize the bug. It is a reason to respect how much authority these libraries carry. MIT krb5 is a mature, widely deployed component precisely because it has spent decades disappearing into the background. Mature does not mean frozen; it means the code is asked to operate correctly in more deployment shapes than any one maintainer can reasonably simulate.
The most useful lesson here is not “C is unsafe,” although C certainly makes this class of failure easier to create. The lesson is that protocol negotiation code deserves the same suspicion as cryptographic code. It is reachable before authentication succeeds, it consumes attacker-controlled structure, and it often runs inside processes administrators cannot casually restart without consequences.
The Windows Angle Is Hybrid Identity, Not Patch Tuesday Theater
WindowsForum readers live in the gravitational field of Microsoft identity, so every Kerberos advisory tends to raise the same immediate question: what does this mean for Active Directory? The answer is nuanced. Active Directory’s Kerberos service is not MIT krb5, but many services joined to or integrated with AD rely on MIT krb5 libraries to accept Kerberos tickets or negotiate security contexts.That is especially common in Linux-heavy estates that still use AD as the account source. A Linux web application might use GSSAPI for integrated authentication. A file service might accept Kerberos-authenticated access. A proxy might front internal resources and translate authentication state across platforms. The user sees “Sign in with Windows credentials,” while the server-side implementation is a patchwork of libraries, PAM modules, service principals, keytabs, and mechanism configuration.
This is why the advisory deserves attention from Windows admins even if it does not demand emergency domain controller patching. The practical exposure follows trust relationships, not branding. If a service participates in the same identity fabric users depend on, a crash in that service is still a Windows environment problem from the user’s point of view.
It also lands during a period when Microsoft has been tightening Kerberos defaults and pushing organizations away from weaker legacy behavior such as RC4 dependence. That broader hardening work is separate from CVE-2026-40356, but it creates the same operational mood: old Kerberos assumptions are being reexamined, and cross-platform authentication dependencies are no longer safe to leave undocumented.
The Real Inventory Starts With Services, Not Packages
The obvious remediation is to update MIT Kerberos 5 to version 1.22.3 or later, or consume the relevant backported package from a trusted distribution vendor. That is necessary, but it is not sufficient as an operational plan. A package inventory can tell you where vulnerable code exists; it cannot always tell you where the vulnerable code is reachable.The better first pass is service-oriented. Which systems accept inbound GSS-API security contexts? Which ones expose Kerberos-capable authentication over the network? Which ones have NegoEx configured in
/etc/gss/mech? Which processes link against the affected libraries but are not actually reachable by untrusted clients?This distinction matters because enterprise patching is a scheduling problem as much as a technical one. If a vulnerable library is present on a build host with no exposed GSS-API accepting service, it still needs updating, but it probably does not outrank an internet-facing or partner-facing authentication gateway. If a storage appliance or application server accepts Kerberos from a broad internal network, it may deserve expedited handling even with a medium score.
Administrators should also resist the temptation to remove mechanism entries blindly unless they understand the dependency. Disabling NegoEx may reduce exposure in some environments, but it can also break clients that rely on negotiation behavior. A controlled package update is usually the cleaner fix; configuration mitigation is for cases where patching is delayed and testing confirms the mechanism is unnecessary.
Crash Bugs Are Monitoring Problems Before They Become Patch Problems
A good response to CVE-2026-40356 should include logs, not just packages. The described failure mode can terminate a process inparse_message, which means defenders should look for unexplained restarts, segmentation faults, core dumps, watchdog recovery events, and authentication failures that cluster around a service rather than a user account.That last point is important. Credential attacks usually leave identity-shaped traces: failed logons, bad passwords, suspicious principals, unusual ticket requests. Parser-level denial of service may look more like infrastructure instability. Users report that single sign-on is flaky, a daemon restarts repeatedly, or a service becomes unreachable under load. The security signal is buried under availability noise.
Organizations with EDR or systemd journal aggregation should be able to correlate restarts with inbound authentication attempts. Those without centralized logs will have a harder time distinguishing attempted exploitation from ordinary fragility. That is one reason availability vulnerabilities are often under-investigated: they can be dismissed as operational gremlins until someone proves the crash is externally triggerable.
Rate limiting and network segmentation can help blunt repeated attempts, but they are not substitutes for fixing the parser. If the vulnerable service must accept Kerberos negotiation from a large internal population, an attacker who already has a foothold inside the network may not need much bandwidth to cause repeated pain.
Vendors Will Decide How Quickly This Reaches Real Machines
MIT krb5 version numbers are useful for upstream clarity, but many production systems do not run upstream tarballs. They run distribution packages with backported fixes, appliance firmware, container base images, or vendor-supported stacks that may keep an older apparent version while carrying the patch. That is normal, but it complicates verification.For Debian, Ubuntu, Red Hat, SUSE, and other enterprise Linux ecosystems, the real question is the vendor advisory state and package changelog, not merely whether
krb5-config --version prints 1.22.3. For containers, the question is whether the base image has been rebuilt and redeployed, not whether the host has been patched. For appliances, the question is whether the vendor has acknowledged and shipped a fixed bundle.This lag is where medium-severity bugs can linger. They may not trigger executive attention, but they remain reachable in the obscure systems that nobody rebuilds often: older middleware servers, lab-to-production “temporary” services, internal portals, monitoring gateways, and file services that have not been through a full dependency refresh in years.
The most disciplined organizations will treat this as a chance to test their identity-component inventory. If they cannot answer which services use MIT krb5 for GSS-API acceptance, the vulnerability has already revealed a process gap. The patch fixes the underflow; the inventory fixes the blind spot.
The Kerberos Trust Boundary Keeps Moving
Kerberos was designed for a world where authenticated principals and trusted services occupied well-understood administrative domains. Modern enterprise use is messier. Cloud migrations, Linux workloads, SaaS integrations, container platforms, and legacy Windows applications all lean on Kerberos in different ways, often through libraries and adapters that only a few specialists fully understand.That makes negotiation-layer vulnerabilities disproportionately interesting. The attacker is not attacking the cryptographic heart of Kerberos or forging tickets. The attacker is abusing the code that tries to understand what kind of security conversation is about to happen. It is a reminder that authentication systems have edges, and those edges can fail before the system reaches the part administrators think of as “the Kerberos bit.”
NegoEx exists because environments need extensibility. Extensibility creates more states, more structures, and more opportunities for malformed input to surprise parsers. That is not an argument against NegoEx or against Kerberos interoperability. It is an argument for treating identity glue as attack surface rather than plumbing.
The industry has become better at hardening the obvious endpoints: domain controllers, identity providers, privileged access systems, and cloud control planes. The next layer of risk lives in the connective tissue. CVE-2026-40356 is not catastrophic by itself, but it points at that connective tissue with unusual clarity.
The Practical Read for Windows-Centric Shops
For a Windows-centric organization, the right response is neither panic nor dismissal. This is not a headline-grabbing Windows domain takeover. It is also not irrelevant just because the affected code is MIT krb5. The organizations most likely to care are the ones that have successfully integrated Windows identity with non-Windows services and then stopped thinking about the mechanics.A sensible response begins by asking Unix, identity, application, and security teams the same question in the same meeting: where do we accept Kerberos or GSS-API authentication outside Windows Server? That conversation will surface systems that do not appear in a simple “Kerberos” dashboard. It may also reveal unsupported packages, stale containers, or vendor products whose authentication libraries are inherited rather than actively managed.
The next step is to verify NegoEx registration. The vulnerable condition depends on a NegoEx mechanism being registered in
/etc/gss/mech, so affected hosts should be identifiable with basic configuration review. That does not mean every configured host is exploitable from every network segment, but it gives defenders a concrete triage handle.Finally, administrators should patch with the seriousness they reserve for infrastructure dependencies. Authentication libraries are not convenience packages. When they fail, users do not experience “a library crash”; they experience inability to reach mail, files, dashboards, shells, repositories, or internal applications.
The Short List Before This Becomes Another Forgotten CVE
CVE-2026-40356 is manageable precisely because the conditions are specific. The danger is that specificity becomes an excuse for nobody to own it. Treat this as a targeted identity-infrastructure cleanup rather than a generic vulnerability scan finding.- Systems running MIT Kerberos 5 before 1.22.3 should be updated through upstream or vendor-supported packages that include the NegoEx parsing fix.
- Hosts with a NegoEx mechanism registered in
/etc/gss/mechdeserve priority review, especially if they accept inbound GSS-API authentication from broad networks. - Windows domain controllers are not the obvious affected component, but Linux and appliance services integrated with Active Directory may still expose the vulnerable code path.
- Monitoring should look for unexplained crashes, service restarts, and authentication outages around Kerberos-enabled applications, not just failed logon events.
- Configuration workarounds should be tested carefully because removing negotiation mechanisms can break legitimate interoperability in mixed Windows and Unix environments.
References
- Primary source: MSRC
Published: 2026-06-03T01:43:26-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: sentinelone.com
CVE-2026-40356: MIT Kerberos 5 DOS Vulnerability
CVE-2026-40356 is a denial of service vulnerability in MIT Kerberos 5. Learn about its impact, affected versions, and mitigation methods.www.sentinelone.com
- Related coverage: dbugs.ptsecurity.com
CVE-2026-40356 — Mit Kerberos 5+1 | dbugs
Details on CVE-2026-40356: Mit Kerberos 5+1. Includes CVSS score, affected versions, and references.dbugs.ptsecurity.com
- Related coverage: service.securitm.ru
CVE-2026-40356 - CVE уязвимости - SECURITM
In MIT Kerberos 5 (aka krb5) before 1.22.3, there is an integer underflow and resultant out-of-bounds read if an application...service.securitm.ru
- Official source: techcommunity.microsoft.com
Phase 2 of Kerberos RC4 hardening begins with the April 2026 Windows security update | Microsoft Community Hub
Windows updates released in April 2026 and later begin the second deployment phase of protections designed to address a Kerberos information...
techcommunity.microsoft.com
- Official source: learn.microsoft.com
Detect and Remediate RC4 Usage in Kerberos
Learn how to detect and limit or disable RC4 usage in Kerberos to enhance security in Active Directory domain environments.learn.microsoft.com
- Related coverage: cems.fun
Advisory - Kerberos (krb5) Two Unauthenticated Network Vulnerabilities: CVE-2026-40355 & CVE-2026-40356
Management Summarycems.fun
