CVE-2026-6324 is a newly cataloged libsoup HTTP request-smuggling flaw, published by NVD on May 29, 2026 and last modified June 17, affecting scenarios where libsoup sits behind a non-libsoup proxy or in front of a non-libsoup backend. Its CVSS 3.1 score is only 4.8, but the number undersells the kind of boundary confusion that makes request smuggling persistently awkward for defenders. This is not a “drop everything” bug for every Linux desktop or server, but it is exactly the sort of middle-layer vulnerability that can become serious when hidden inside reverse proxies, embedded applications, package dependencies, and long-lived enterprise images.
The core of CVE-2026-6324 is not that libsoup crashes, leaks memory, or hands an attacker a shell. It is that libsoup may interpret part of an HTTP request differently from another component in the same traffic path. That is the classic shape of HTTP request smuggling: one parser believes the request ends in one place, while another believes there is more request data waiting behind it.
The reported flaw sits in
The important qualifier is the deployment condition. The vulnerability matters when libsoup is paired with a different HTTP implementation across a trust boundary: behind a non-libsoup proxy, or acting as a proxy in front of a non-libsoup backend. In other words, the danger is not simply “libsoup parses HTTP badly.” The danger is “libsoup and its neighbor disagree about what the same bytes mean.”
That distinction should shape the response. A local desktop app using libsoup to fetch a web page is not the same risk as a service stack where libsoup is part of a proxying path, authentication gateway, cache, API broker, or appliance-like product. The affected library may be common, but the exploitable architecture is narrower.
Request smuggling bugs frequently live in the uncomfortable zone between “not critical by scoring math” and “very relevant to real systems.” They often require a very specific chain: a frontend that accepts one framing interpretation, a backend that accepts another, and some security decision made by only one side of the chain. That complexity lowers the score, yet the payoff can be meaningful if the smuggled request lands behind authentication, cache controls, or routing policy.
This is why defenders should read CVE-2026-6324 as an architectural warning rather than a generic package alert. The question is not simply whether
That is also where vulnerability management tooling tends to flatten nuance. A scanner can tell you that a package is installed. It may not know whether the library is used in a request path where a non-libsoup proxy and a libsoup component disagree about chunked bodies. This is one of those cases where asset context matters more than the red or yellow square in a dashboard.
That is part of the challenge. Libraries like libsoup do not always announce themselves as “internet-facing infrastructure.” They arrive as dependencies, graphical stack components, language bindings, embedded service helpers, package-manager conveniences, or internal HTTP clients. In a normal vulnerability triage meeting, they risk being filed under desktop Linux noise unless somebody asks what the package is actually doing on a given system.
The Red Hat affected-product list spans RHEL 6 through RHEL 10, with
Those distro differences matter less than the broader pattern. The vulnerable code lineage exists across multiple Linux ecosystems, and the fix status depends on vendor packaging cadence. Administrators should not assume that upstream has solved the problem everywhere just because a commit exists, nor should they assume exposure just because a package appears in inventory.
Chunked transfer encoding is fertile ground for this class of bug because it exists to define where pieces of the body begin and end. If an implementation mishandles a chunk size, signedness, truncation, overflow, or malformed boundary, the stream can become ambiguous. One side may believe a request body has ended; the other may treat leftover bytes as the start of the next request.
That is why the CVE’s mention of cache poisoning and unauthorized access is not generic boilerplate. If a frontend and backend disagree, an attacker may be able to sneak a request past a control that only inspected the “first” request, or corrupt a cache entry that later users receive. The exploit does not need to be cinematic to be useful.
The high attack complexity rating is still important. Exploitation depends on deployment topology, parser behavior in adjacent components, and whether the target path has something worth bypassing. A reverse proxy with strict normalization and no vulnerable libsoup component in the forwarding chain may be unaffected in practice. A bespoke application server using libsoup in front of another HTTP server could be more interesting.
That middle ground is where many organizations make poor decisions. Security teams drowning in critical CVEs may defer a medium issue indefinitely. Attackers, meanwhile, do not care about severity labels if a bug opens a path through an authentication layer, cache, or internal service boundary in a specific environment.
The better reading is pragmatic. CVE-2026-6324 is not a universal emergency, but it deserves accelerated review wherever libsoup participates in proxy-like behavior, backend request handling, internal web gateways, or appliances that bridge HTTP components. The systems at risk are not necessarily the ones with the most public exposure; they may be the internal services where teams assume proxy boundaries are trustworthy.
There is also a supply-chain dimension. Many administrators will not knowingly deploy “a libsoup server.” They will deploy an application, container, virtual appliance, desktop service, or agent that happens to carry libsoup. If that software accepts HTTP traffic and forwards it, the library dependency becomes operationally relevant.
A Windows-heavy organization may still rely on Linux reverse proxies, Linux application containers, GNOME-derived components in virtual desktop environments, or open-source agents that include libsoup. Even if domain controllers, endpoints, and management consoles are Windows-first, the HTTP infrastructure surrounding them is often heterogeneous. Vulnerabilities in the glue layer can affect the Windows estate indirectly.
That is especially true for cache poisoning and access-control bypass. If an affected Linux component sits in front of an internal web app used by Windows admins, the risk is not confined to the Linux host. The vulnerable component becomes a weak link in a trust path that may protect credentials, management interfaces, or internal APIs.
The practical Windows angle is therefore inventory and architecture, not panic. Check container images, Linux VM baselines, WSL developer environments that run services, and appliance documentation. If libsoup appears only as an unused desktop dependency on a sealed image, the risk is low. If it appears inside a request-processing component that shares traffic with a different HTTP stack, the risk deserves attention.
This is normal for open-source infrastructure bugs. Upstream may land a patch before every downstream vendor has packaged, tested, backported, and shipped it. Enterprise distributions may classify the issue differently depending on supported versions and likely exposure. Some trackers will call it minor; scanner vendors may flag it as unpatched; administrators then have to reconcile both statements.
The upstream reference to a fix commit and merge request is useful, but most production teams should not treat upstream source as their operational source of truth. For managed systems, the safer path is to follow the distribution vendor’s security advisory and package stream. Backported fixes often preserve old version numbers or apply patches without jumping to the latest upstream release, which can confuse simplistic version checks.
There is also a support boundary to consider. RHEL 6 and other older lines may appear in affected metadata, but not every listed product line receives the same public patch treatment under normal support. Extended lifecycle arrangements, vendor subscriptions, and third-party rebuilds can change the answer. The worst outcome is not “we waited two days for vendor packages”; it is “we assumed a package was safe because upstream fixed a different branch.”
For many systems, the answer will be boring. A desktop dependency that is not listening for traffic is not the same as an externally reachable service. An application that uses libsoup only as an outbound client may not meet the described vulnerable topology. But a service that accepts HTTP, parses chunked bodies, and forwards requests into a different backend deserves a closer look.
Logs may not make this easy. Request smuggling often manipulates the gray area between requests, so ordinary access logs can show one component’s interpretation while another component processed something else. If an organization has frontend and backend logs with request IDs, timing, and connection reuse data, those become more valuable than usual.
Mitigations short of patching are also topology-dependent. Normalizing or rejecting ambiguous chunked requests at the edge may help. Disabling unnecessary proxying paths may help. Avoiding mixed parser chains where libsoup and another server share persistent connections may help. But these are compensating controls, not substitutes for vendor fixes.
The industry has improved, but it has not eliminated parser disagreement. HTTP/2 and HTTP/3 reduce some old HTTP/1.1 ambiguity while introducing translation layers of their own. Many real deployments still downgrade, upgrade, tunnel, terminate TLS, translate protocols, and hand traffic from one component to another. The messy middle remains.
That is why “use a mature proxy” is not a complete answer. Mature proxies are valuable, but request smuggling often emerges from combinations rather than isolated incompetence. A frontend can be correct by its own rules and still become dangerous when paired with a backend that accepts a different edge case. Security depends on the composition.
For developers, the lesson is equally blunt. HTTP parsing should not be treated as casual string handling, and signedness bugs in size fields are not harmless implementation details. If a library reads chunk sizes, request bodies, or framing boundaries, type conversions become security decisions.
A request-smuggling flaw in such a path can produce uncomfortable outcomes. An attacker with network access to an internal service may be able to reach endpoints the frontend would normally restrict. A poisoned cache may serve incorrect content to privileged users. A backend may see a request with headers, paths, or authentication context that the frontend did not intend to pass.
The CVE text’s “unauthorized access” phrase should not be read as guaranteed account takeover. It should be read as a warning about control-plane confusion. If one component enforces the rule and another component receives the smuggled request, the attacker’s goal is to make the wrong component answer the wrong question.
That makes network segmentation relevant but not decisive. If the affected service is reachable only from a limited management network, risk is reduced. If that management network includes jump boxes, CI systems, developer laptops, and shared tooling, the practical attack surface may still be broad enough to matter.
The correct response is targeted. Identify affected packages, identify exposed or proxying uses, prioritize mixed-parser HTTP paths, and patch according to vendor guidance. If the vulnerable library is present but not in the described topology, document the rationale and move on. If it is present in a request boundary, escalate the fix.
This is also a good moment to test whether vulnerability-management data is connected to runtime reality. Can the team determine which services load libsoup? Can it map HTTP chains from edge to backend? Can it distinguish an installed but dormant library from one sitting in the path of attacker-controlled requests? If not, this medium CVE is exposing a larger operational blind spot.
For developers shipping products that embed libsoup, the bar is higher. Customers should not have to reverse-engineer whether an appliance or application uses libsoup in a vulnerable role. Clear advisories, fixed builds, and configuration guidance are the difference between a manageable library bug and weeks of speculative scanning.
The Vulnerability Lives in the Gap Between Two HTTP Interpreters
The core of CVE-2026-6324 is not that libsoup crashes, leaks memory, or hands an attacker a shell. It is that libsoup may interpret part of an HTTP request differently from another component in the same traffic path. That is the classic shape of HTTP request smuggling: one parser believes the request ends in one place, while another believes there is more request data waiting behind it.The reported flaw sits in
soup_body_input_stream_read_chunked(), the chunked-body reading path. Red Hat describes the bug as an unsigned-to-signed conversion error, which is the kind of low-level type mismatch C and C-adjacent network stacks have been paying for since the beginning of web infrastructure. When that mistake touches HTTP framing, it can stop being a mere correctness bug and become a routing, authentication, or cache-integrity problem.The important qualifier is the deployment condition. The vulnerability matters when libsoup is paired with a different HTTP implementation across a trust boundary: behind a non-libsoup proxy, or acting as a proxy in front of a non-libsoup backend. In other words, the danger is not simply “libsoup parses HTTP badly.” The danger is “libsoup and its neighbor disagree about what the same bytes mean.”
That distinction should shape the response. A local desktop app using libsoup to fetch a web page is not the same risk as a service stack where libsoup is part of a proxying path, authentication gateway, cache, API broker, or appliance-like product. The affected library may be common, but the exploitable architecture is narrower.
A Medium Score Can Still Describe a High-Value Boundary
The CVSS 3.1 vector assigned by Red Hat lands at 4.8, with network attack vector, high attack complexity, no privileges required, no user interaction, unchanged scope, and low confidentiality and integrity impact. That is a bureaucratically precise way of saying the bug is reachable over the network but requires a particular arrangement and produces partial compromise rather than immediate system takeover. It is a reasonable score, but it is not a reason to ignore the issue.Request smuggling bugs frequently live in the uncomfortable zone between “not critical by scoring math” and “very relevant to real systems.” They often require a very specific chain: a frontend that accepts one framing interpretation, a backend that accepts another, and some security decision made by only one side of the chain. That complexity lowers the score, yet the payoff can be meaningful if the smuggled request lands behind authentication, cache controls, or routing policy.
This is why defenders should read CVE-2026-6324 as an architectural warning rather than a generic package alert. The question is not simply whether
libsoup or libsoup3 exists on a host. The question is whether that host uses libsoup in a position where HTTP requests cross from one parser’s worldview into another’s.That is also where vulnerability management tooling tends to flatten nuance. A scanner can tell you that a package is installed. It may not know whether the library is used in a request path where a non-libsoup proxy and a libsoup component disagree about chunked bodies. This is one of those cases where asset context matters more than the red or yellow square in a dashboard.
Libsoup Is Small Enough to Miss and Common Enough to Matter
Libsoup is not NGINX, Apache, IIS, or HAProxy. It does not usually appear in architecture diagrams with a big box around it. It is a GNOME-origin HTTP client/server library used by desktop components and applications, and over time it has appeared in enough network-aware software that administrators may find it installed in places they did not explicitly design around.That is part of the challenge. Libraries like libsoup do not always announce themselves as “internet-facing infrastructure.” They arrive as dependencies, graphical stack components, language bindings, embedded service helpers, package-manager conveniences, or internal HTTP clients. In a normal vulnerability triage meeting, they risk being filed under desktop Linux noise unless somebody asks what the package is actually doing on a given system.
The Red Hat affected-product list spans RHEL 6 through RHEL 10, with
libsoup on older lines and libsoup3 on RHEL 10. Ubuntu’s security metadata similarly identifies both libsoup 2.4 and libsoup 3 families across supported releases, including LTS versions. Debian’s tracker, meanwhile, still marked relevant source packages vulnerable or unfixed at the time of the referenced tracker snapshot, while labeling the issue minor for some stable releases.Those distro differences matter less than the broader pattern. The vulnerable code lineage exists across multiple Linux ecosystems, and the fix status depends on vendor packaging cadence. Administrators should not assume that upstream has solved the problem everywhere just because a commit exists, nor should they assume exposure just because a package appears in inventory.
The Real Attack Is Parser Disagreement, Not a Magic Packet
HTTP request smuggling succeeds because modern web stacks are really chains of interpreters. A client speaks to a frontend. The frontend normalizes, routes, caches, authenticates, logs, or rate-limits the request. Then it forwards something to a backend, which may parse the stream again and reach a different conclusion about boundaries.Chunked transfer encoding is fertile ground for this class of bug because it exists to define where pieces of the body begin and end. If an implementation mishandles a chunk size, signedness, truncation, overflow, or malformed boundary, the stream can become ambiguous. One side may believe a request body has ended; the other may treat leftover bytes as the start of the next request.
That is why the CVE’s mention of cache poisoning and unauthorized access is not generic boilerplate. If a frontend and backend disagree, an attacker may be able to sneak a request past a control that only inspected the “first” request, or corrupt a cache entry that later users receive. The exploit does not need to be cinematic to be useful.
The high attack complexity rating is still important. Exploitation depends on deployment topology, parser behavior in adjacent components, and whether the target path has something worth bypassing. A reverse proxy with strict normalization and no vulnerable libsoup component in the forwarding chain may be unaffected in practice. A bespoke application server using libsoup in front of another HTTP server could be more interesting.
The Proof-of-Concept Signal Cuts Both Ways
CISA’s SSVC enrichment reportedly marks exploitation as “poc,” automatable as “no,” and technical impact as “partial.” That combination is worth parsing carefully. Proof-of-concept availability means defenders should assume the bug is no longer theoretical, but “not automatable” and “partial” indicate this is not currently the kind of commodity worm fuel that burns across the internet overnight.That middle ground is where many organizations make poor decisions. Security teams drowning in critical CVEs may defer a medium issue indefinitely. Attackers, meanwhile, do not care about severity labels if a bug opens a path through an authentication layer, cache, or internal service boundary in a specific environment.
The better reading is pragmatic. CVE-2026-6324 is not a universal emergency, but it deserves accelerated review wherever libsoup participates in proxy-like behavior, backend request handling, internal web gateways, or appliances that bridge HTTP components. The systems at risk are not necessarily the ones with the most public exposure; they may be the internal services where teams assume proxy boundaries are trustworthy.
There is also a supply-chain dimension. Many administrators will not knowingly deploy “a libsoup server.” They will deploy an application, container, virtual appliance, desktop service, or agent that happens to carry libsoup. If that software accepts HTTP traffic and forwards it, the library dependency becomes operationally relevant.
Windows Shops Should Not Dismiss This as Someone Else’s Linux Problem
For WindowsForum readers, the obvious temptation is to put CVE-2026-6324 in the Linux pile and move on. That would be tidy, and in many home-user Windows environments it would also be mostly correct. But mixed estates, WSL workflows, Linux-based appliances, containers, CI runners, developer desktops, and proxy-adjacent services make the boundary blurrier than the operating-system label suggests.A Windows-heavy organization may still rely on Linux reverse proxies, Linux application containers, GNOME-derived components in virtual desktop environments, or open-source agents that include libsoup. Even if domain controllers, endpoints, and management consoles are Windows-first, the HTTP infrastructure surrounding them is often heterogeneous. Vulnerabilities in the glue layer can affect the Windows estate indirectly.
That is especially true for cache poisoning and access-control bypass. If an affected Linux component sits in front of an internal web app used by Windows admins, the risk is not confined to the Linux host. The vulnerable component becomes a weak link in a trust path that may protect credentials, management interfaces, or internal APIs.
The practical Windows angle is therefore inventory and architecture, not panic. Check container images, Linux VM baselines, WSL developer environments that run services, and appliance documentation. If libsoup appears only as an unused desktop dependency on a sealed image, the risk is low. If it appears inside a request-processing component that shares traffic with a different HTTP stack, the risk deserves attention.
Patch Management Will Be Messier Than the CVE Page Suggests
The NVD entry says enrichment is still pending, and that is a reminder that CVE publication is not the same thing as a clean remediation map. Red Hat has provided the CNA description and CVSS vector. Ubuntu metadata points to upstream references and lists affected package families. Debian’s tracker, at least in the snapshot reviewed, shows vulnerable states and upstream references, with fixed-version handling still evolving.This is normal for open-source infrastructure bugs. Upstream may land a patch before every downstream vendor has packaged, tested, backported, and shipped it. Enterprise distributions may classify the issue differently depending on supported versions and likely exposure. Some trackers will call it minor; scanner vendors may flag it as unpatched; administrators then have to reconcile both statements.
The upstream reference to a fix commit and merge request is useful, but most production teams should not treat upstream source as their operational source of truth. For managed systems, the safer path is to follow the distribution vendor’s security advisory and package stream. Backported fixes often preserve old version numbers or apply patches without jumping to the latest upstream release, which can confuse simplistic version checks.
There is also a support boundary to consider. RHEL 6 and other older lines may appear in affected metadata, but not every listed product line receives the same public patch treatment under normal support. Extended lifecycle arrangements, vendor subscriptions, and third-party rebuilds can change the answer. The worst outcome is not “we waited two days for vendor packages”; it is “we assumed a package was safe because upstream fixed a different branch.”
The Triage Starts With Traffic, Not Package Names
A useful response to CVE-2026-6324 begins by identifying where libsoup can process attacker-controlled HTTP traffic. Package inventory is the first pass, not the decision. Once the package is found, administrators need to know which processes load it, which ports those processes expose, and whether any of those processes act as a proxy, bridge, cache, or HTTP-speaking middle tier.For many systems, the answer will be boring. A desktop dependency that is not listening for traffic is not the same as an externally reachable service. An application that uses libsoup only as an outbound client may not meet the described vulnerable topology. But a service that accepts HTTP, parses chunked bodies, and forwards requests into a different backend deserves a closer look.
Logs may not make this easy. Request smuggling often manipulates the gray area between requests, so ordinary access logs can show one component’s interpretation while another component processed something else. If an organization has frontend and backend logs with request IDs, timing, and connection reuse data, those become more valuable than usual.
Mitigations short of patching are also topology-dependent. Normalizing or rejecting ambiguous chunked requests at the edge may help. Disabling unnecessary proxying paths may help. Avoiding mixed parser chains where libsoup and another server share persistent connections may help. But these are compensating controls, not substitutes for vendor fixes.
The Industry Keeps Relearning the Same HTTP Lesson
CVE-2026-6324 belongs to a long line of bugs that exploit HTTP’s age, flexibility, and implementation diversity. The protocol’s text-friendly origins are part of its charm and part of its attack surface. Every proxy, gateway, cache, framework, and library carries assumptions about malformed input, connection reuse, transfer encoding, and request boundaries.The industry has improved, but it has not eliminated parser disagreement. HTTP/2 and HTTP/3 reduce some old HTTP/1.1 ambiguity while introducing translation layers of their own. Many real deployments still downgrade, upgrade, tunnel, terminate TLS, translate protocols, and hand traffic from one component to another. The messy middle remains.
That is why “use a mature proxy” is not a complete answer. Mature proxies are valuable, but request smuggling often emerges from combinations rather than isolated incompetence. A frontend can be correct by its own rules and still become dangerous when paired with a backend that accepts a different edge case. Security depends on the composition.
For developers, the lesson is equally blunt. HTTP parsing should not be treated as casual string handling, and signedness bugs in size fields are not harmless implementation details. If a library reads chunk sizes, request bodies, or framing boundaries, type conversions become security decisions.
The Enterprise Risk Is Concentrated in Boring Places
The most exposed systems may not be the most glamorous. Internal build dashboards, package mirrors, software update services, authentication helpers, remote-management agents, developer portals, monitoring tools, and appliance UIs often sit behind proxies and receive less scrutiny than public web applications. They are also exactly the places where teams rely on layered trust assumptions.A request-smuggling flaw in such a path can produce uncomfortable outcomes. An attacker with network access to an internal service may be able to reach endpoints the frontend would normally restrict. A poisoned cache may serve incorrect content to privileged users. A backend may see a request with headers, paths, or authentication context that the frontend did not intend to pass.
The CVE text’s “unauthorized access” phrase should not be read as guaranteed account takeover. It should be read as a warning about control-plane confusion. If one component enforces the rule and another component receives the smuggled request, the attacker’s goal is to make the wrong component answer the wrong question.
That makes network segmentation relevant but not decisive. If the affected service is reachable only from a limited management network, risk is reduced. If that management network includes jump boxes, CI systems, developer laptops, and shared tooling, the practical attack surface may still be broad enough to matter.
Security Teams Need to Resist Both Overreaction and Underreaction
There are two bad responses available here. The first is to treat CVE-2026-6324 as a critical internet-wide fire drill because the words “request smuggling” sound alarming. The second is to bury it because the score is medium and libsoup sounds like desktop plumbing. Both reactions miss the actual shape of the risk.The correct response is targeted. Identify affected packages, identify exposed or proxying uses, prioritize mixed-parser HTTP paths, and patch according to vendor guidance. If the vulnerable library is present but not in the described topology, document the rationale and move on. If it is present in a request boundary, escalate the fix.
This is also a good moment to test whether vulnerability-management data is connected to runtime reality. Can the team determine which services load libsoup? Can it map HTTP chains from edge to backend? Can it distinguish an installed but dormant library from one sitting in the path of attacker-controlled requests? If not, this medium CVE is exposing a larger operational blind spot.
For developers shipping products that embed libsoup, the bar is higher. Customers should not have to reverse-engineer whether an appliance or application uses libsoup in a vulnerable role. Clear advisories, fixed builds, and configuration guidance are the difference between a manageable library bug and weeks of speculative scanning.
The Patch Is Only Half the Story for Mixed HTTP Stacks
Administrators should treat CVE-2026-6324 as a reminder to examine parser boundaries, not just package versions. The immediate work is finite, but the long-term lesson is about reducing ambiguity between HTTP components that must trust one another.- Systems that use libsoup only as a passive desktop or outbound-client dependency are unlikely to carry the same risk as systems where libsoup parses inbound or proxied HTTP requests.
- The highest-priority environments are mixed HTTP chains where libsoup sits beside a different proxy, gateway, backend server, cache, or application framework.
- Vendor packages should be preferred over ad hoc source upgrades, because enterprise distributions may backport the fix without changing to the newest upstream version.
- Scanner findings need runtime context, since an installed vulnerable package does not prove an exploitable request-smuggling path.
- Edge normalization, stricter handling of ambiguous chunked requests, and review of persistent backend connections can reduce exposure while patches are staged.
- Windows-centric organizations should still check Linux appliances, containers, WSL-hosted services, and internal tooling that may sit in front of Windows administration workflows.
References
- Primary source: NVD
Published: 2026-06-28T01:52:47-07:00
NVD - CVE-2026-6324
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-28T01:52:47-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: vulnerability.circl.lu
Vulnerability-Lookup
Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.vulnerability.circl.lu - Related coverage: security.snyk.io
HTTP Request Smuggling in libsoup2.4 | CVE-2026-6324 | Snyk
Medium severity (4.8) HTTP Request Smuggling in libsoup2.4 | CVE-2026-6324security.snyk.io - Related coverage: vuldb.com
CVE-2026-6324 GNOME libsoup non-libsoup Backend soup_body_input_stream_read_chunked escalada de privilegios
Se ha identificado una vulnerabilidad en GNOME libsoup. Esta vulnerabilidad se conoce como CVE-2026-6324.vuldb.com - Related coverage: tracker.security.nixos.org
