CVE-2026-25680 is a Go vulnerability published on May 22, 2026, affecting golang.org/x/net before version 0.55.0, where the html parser can spend excessive CPU time processing attacker-supplied HTML and cause denial of service in applications that parse untrusted markup. The bug is not glamorous, and that is exactly why it matters. It sits in the quiet plumbing of modern services, where HTML is fetched, sanitized, indexed, previewed, converted, scraped, and analyzed far from the user interface. For Windows developers and administrators running Go services on Windows Server, Azure, containers, or mixed-platform fleets, this is a reminder that availability bugs in open-source libraries can become production incidents without ever looking like a classic exploit.
The phrase “arbitrary HTML” sounds harmless because the web has trained everyone to treat malformed markup as background noise. Browsers tolerate it, crawlers consume it, mail clients mangle it, and security tools dissect it. That culture of tolerance has a cost: once a service agrees to parse whatever markup the outside world provides, it has accepted the parser as part of its attack surface.
CVE-2026-25680 lives in
The affected functions include common parser entry points such as
That makes this a resource exhaustion vulnerability rather than a breach story. There is no public signal here of remote code execution, data theft, or privilege escalation. But a service does not need to lose secrets to fail its users. It only has to stop answering.
That is the reality of Windows-centric IT. A Go module vulnerability can land on the radar of a Microsoft shop because the affected code is embedded in an internal service, bundled into a vendor appliance, shipped inside a developer tool, or included somewhere in a container image running on Windows Server or Azure infrastructure. The old boundary between “Microsoft patching” and “application dependency patching” has become porous.
This is where the security update process often misleads non-specialists. Seeing Microsoft’s name near a CVE does not automatically mean Windows Update will solve it. For many open-source component flaws, the fix is not a monthly cumulative update; it is a rebuild, a module bump, a redeploy, and often a conversation with a vendor that bundled the affected library months earlier.
The practical question for administrators is therefore not “Did I install this month’s Windows patches?” It is “Do any of my deployed applications, services, agents, or third-party products include vulnerable versions of
CVE-2026-25680 is rated in the medium range under CVSS, with availability as the impact and no confidentiality or integrity loss described. That score is reasonable in the abstract. It is also incomplete in the way all generic scoring is incomplete: a CPU-burning parser bug in a rarely used admin tool is a nuisance; the same bug in an internet-facing content ingestion pipeline can become a production outage.
The user-supplied description emphasizes total loss of availability, sustained while the attacker continues to deliver the attack or persistent when the condition outlasts the attack. That framing is more operational than theoretical. It acknowledges that a denial-of-service flaw does not have to crash a binary outright to be serious; tying up workers, saturating CPU, starving queues, and preventing new requests can be enough.
WindowsForum readers have seen this pattern in other forms: print spooler queues that jam, IIS worker processes that recycle under pressure, endpoint agents that peg a CPU core, or indexing services that collapse under malformed content. The root cause differs, but the administrative experience is the same. A component that exists to automate work becomes the thing consuming the machine.
Go is especially common in this layer because it is a strong fit for network services: easy cross-compilation, static binaries, straightforward concurrency, and a rich ecosystem of modules. That means
This is where “arbitrary HTML” becomes a warning label. If the service fetches URLs submitted by users, accepts rich text from external accounts, processes inbound email, or crawls partner content, the parser is effectively reachable by attackers. The exploit path may be indirect, but indirect does not mean implausible.
The rise of AI and automation makes the exposure larger. Retrieval systems, knowledge-base importers, support bots, and internal search tools increasingly ingest web pages and HTML-rich documents at scale. These systems often run behind authentication, which can make teams feel safe, but many of them accept content from semi-trusted sources. A parser that burns CPU on malicious markup can turn a convenient ingestion job into a denial-of-service lever.
Modern organizations do not merely have source repositories. They have built artifacts, containers, vendored dependencies, forked modules, CI caches, old release branches, appliance images, developer utilities, and third-party binaries. A vulnerable module version in
Go’s static binary model is a gift to deployment and a headache for forensic dependency management. A single executable can carry all the relevant library code inside it, with no shared DLL sitting on disk to patch centrally. That simplicity is one reason Go services are so portable. It is also why vulnerability response must happen at build time, not by replacing a file in
On Windows fleets, this distinction is particularly important because administrators are used to central patching workflows. WSUS, Microsoft Intune, Configuration Manager, Defender vulnerability signals, and vendor update channels can cover a great deal. They cannot automatically upgrade an internal Go service whose dependencies were frozen in a build pipeline six months ago.
The mature response is inventory first, remediation second. Teams need to identify applications that depend on
That includes internal web services built in Go and deployed as Windows services. It includes containerized workloads hosted on Windows nodes. It includes cross-platform agents, developer tools, observability collectors, security scanners, and vendor products whose internals are not obvious from their user interfaces. If those tools parse HTML from untrusted sources, the operating system underneath is mostly incidental.
This indirectness creates a gap between ownership models. The Windows admin may own the server. The application team may own the code. A vendor may own the binary. The security team may own the vulnerability report. The cloud team may own the deployment platform. Availability risk falls through those seams unless somebody is accountable for the full runtime stack.
For sysadmins, the immediate operational signal is CPU behavior. A vulnerable parser attack may look like sudden CPU saturation, thread starvation, queue buildup, increased request latency, health-check failures, or autoscaling churn. It may not produce a neat crash dump or a clear security log entry. If a service processes HTML and suddenly consumes abnormal CPU while handling odd-looking content, this CVE belongs in the hypothesis list.
For developers, the signal is dependency reachability. If code paths parse remote pages, uploaded HTML, email bodies, chat messages, issue descriptions, CMS exports, or scraped fragments, the parser is reachable. If those code paths run synchronously on request-handling workers, the risk is higher. If they run in bounded background jobs with strict timeouts and concurrency limits, the risk is lower but not gone.
The attack complexity is low enough to take seriously, but user interaction is part of the scoring because an application generally has to parse supplied content. That does not necessarily mean a human must click a malicious page in the browser. In server-side systems, “interaction” can be an application accepting a submitted URL, processing an uploaded file, importing a feed, or fetching content on behalf of a user.
This nuance matters because many teams wrongly equate user interaction with phishing. Here, the interaction may be architectural. If the business logic is designed to consume untrusted HTML, then the application is cooperating with the attacker by design.
The absence of confidentiality and integrity impact should also not lull infrastructure teams. Availability is a first-class security property for authentication portals, monitoring systems, support platforms, billing services, and deployment pipelines. A parser bug that knocks out a customer-facing preview service is annoying. The same class of bug affecting a security gateway or automation controller can have wider consequences.
There is also a compounding effect. CPU exhaustion in one service can cascade into retry storms, queue growth, autoscaling costs, database pressure, and noisy alerts that obscure other incidents. Denial of service rarely stays perfectly contained in a distributed system. It finds the dependencies that were sized for normal behavior.
That is not because Go is uniquely unsafe. It is because parsers are complex by nature. They translate hostile ambiguity into structured data. HTML is especially messy because real-world markup is malformed, nested, duplicated, truncated, and full of historical browser compatibility traps. An attacker does not need a buffer overflow if an algorithmic corner case gives them a cheaper path to exhaustion.
The safest architecture isolates parsing work from request-critical paths. A web request should not be able to monopolize a worker indefinitely because it submitted a malicious fragment. Parsing jobs should run with context deadlines, input caps, worker pools, and back-pressure. If the system must fetch remote HTML, it should also enforce response size limits and fetch timeouts before the parser ever sees the bytes.
Sanitization is not a complete answer if it relies on the same vulnerable parsing path. Teams sometimes say “we sanitize HTML before parsing it,” but sanitizers usually parse too. The mitigation has to happen outside or before the expensive operation: limit what is accepted, cap how much is processed, and constrain the resources available to the parser.
For Windows operators, service-level guardrails still matter. Process isolation, CPU quotas in containers, job objects, service recovery policies, health probes, and rate limiting at reverse proxies can reduce blast radius. These controls do not replace the library update, but they can turn a total outage into a degraded queue and a page to the on-call engineer instead of a customer-visible collapse.
This is where software bills of materials become practical rather than bureaucratic. If an organization can answer which deployed binaries include
Go teams have useful tooling, including module metadata, vulnerability scanning, and reproducible build practices. But tools only help when wired into release workflows. A scan that runs in a developer laptop is not the same as a policy gate in CI. A dependency alert in a repository is not the same as proof that production has been rebuilt and redeployed.
Vendor management belongs in the same conversation. Many Windows environments run commercial tools that include Go components. Customers may not see the dependency directly, but they still inherit its risk. Procurement and security teams should be asking vendors not only whether they are affected, but which product versions contain the fix and whether mitigations are available before an upgrade window.
The hard part is not writing the patch command. It is maintaining enough visibility that the patch command can be aimed at the right targets. CVE-2026-25680 rewards organizations that already know what they are running.
Memory safety reduces entire categories of bugs, but it does not eliminate algorithmic complexity. Static binaries reduce deployment friction, but they do not remove the need to rebuild after dependency fixes. A small service written in a clean language can still expose a high-value endpoint to malformed input and fall over under pressure.
The Go ecosystem’s response model is relatively healthy: publish advisories, identify affected symbols, mark fixed versions, and provide references to changes. That transparency helps defenders. But no language ecosystem can reach into every enterprise and redeploy old binaries.
This is especially relevant for Windows-heavy organizations that adopted Go quietly. The first wave of Go in many enterprises came through infrastructure tools rather than line-of-business applications: agents, CLIs, exporters, proxies, schedulers, and automation services. Those tools may not be owned by traditional application teams, and their dependency posture may be less visible.
The result is a new kind of patch Tuesday that does not arrive on Tuesday. Language ecosystems, container registries, GitHub advisories, vendor bulletins, and Microsoft security listings now all feed the same remediation calendar. Administrators who treat only operating-system patches as real patches are fighting the last decade’s war.
The Dangerous Part Is Not HTML, It Is Trust
The phrase “arbitrary HTML” sounds harmless because the web has trained everyone to treat malformed markup as background noise. Browsers tolerate it, crawlers consume it, mail clients mangle it, and security tools dissect it. That culture of tolerance has a cost: once a service agrees to parse whatever markup the outside world provides, it has accepted the parser as part of its attack surface.CVE-2026-25680 lives in
golang.org/x/net/html, not in Go’s compiler, runtime, or Windows itself. That distinction will tempt some teams to downgrade it as “just a dependency issue.” In practice, dependency issues are now where much of the operational risk lives, because developers rarely deploy languages; they deploy dependency graphs.The affected functions include common parser entry points such as
Parse, ParseFragment, ParseWithOptions, and ParseFragmentWithOptions. Those are exactly the sorts of functions that appear in services that scrape pages, ingest user-submitted content, generate link previews, clean HTML fragments, process email bodies, or extract metadata from third-party sites. If an attacker can feed such a service pathological input, the exploit primitive is not memory corruption. It is wasted time.That makes this a resource exhaustion vulnerability rather than a breach story. There is no public signal here of remote code execution, data theft, or privilege escalation. But a service does not need to lose secrets to fail its users. It only has to stop answering.
Microsoft’s Listing Turns a Go Bug Into an Enterprise Patch Item
The notable twist is Microsoft’s involvement through the Security Update Guide. Microsoft did not invent this Go parser, and Windows is not the vulnerable component in the narrow sense. Yet the appearance of CVE-2026-25680 in Microsoft’s vulnerability ecosystem matters because many enterprise teams organize remediation around Microsoft’s security channels, not around every upstream language advisory.That is the reality of Windows-centric IT. A Go module vulnerability can land on the radar of a Microsoft shop because the affected code is embedded in an internal service, bundled into a vendor appliance, shipped inside a developer tool, or included somewhere in a container image running on Windows Server or Azure infrastructure. The old boundary between “Microsoft patching” and “application dependency patching” has become porous.
This is where the security update process often misleads non-specialists. Seeing Microsoft’s name near a CVE does not automatically mean Windows Update will solve it. For many open-source component flaws, the fix is not a monthly cumulative update; it is a rebuild, a module bump, a redeploy, and often a conversation with a vendor that bundled the affected library months earlier.
The practical question for administrators is therefore not “Did I install this month’s Windows patches?” It is “Do any of my deployed applications, services, agents, or third-party products include vulnerable versions of
golang.org/x/net and expose the HTML parser to untrusted input?” Those are different questions, answered by different inventories.Availability Bugs Age Differently From Code Execution Bugs
Security teams are trained to triage remote code execution quickly because the failure mode is vivid. An attacker runs code, establishes persistence, moves laterally, and the incident response plan comes alive. Denial of service is less cinematic, which is why it is so often underweighted until the help desk lights up.CVE-2026-25680 is rated in the medium range under CVSS, with availability as the impact and no confidentiality or integrity loss described. That score is reasonable in the abstract. It is also incomplete in the way all generic scoring is incomplete: a CPU-burning parser bug in a rarely used admin tool is a nuisance; the same bug in an internet-facing content ingestion pipeline can become a production outage.
The user-supplied description emphasizes total loss of availability, sustained while the attacker continues to deliver the attack or persistent when the condition outlasts the attack. That framing is more operational than theoretical. It acknowledges that a denial-of-service flaw does not have to crash a binary outright to be serious; tying up workers, saturating CPU, starving queues, and preventing new requests can be enough.
WindowsForum readers have seen this pattern in other forms: print spooler queues that jam, IIS worker processes that recycle under pressure, endpoint agents that peg a CPU core, or indexing services that collapse under malformed content. The root cause differs, but the administrative experience is the same. A component that exists to automate work becomes the thing consuming the machine.
The Parser Is the New Perimeter
HTML parsing used to be discussed mostly as a browser problem. That mental model is obsolete. Today, HTML is parsed by server-side preview generators, AI ingestion tools, email gateways, static-site importers, ticketing systems, documentation portals, compliance scanners, search crawlers, and chat integrations.Go is especially common in this layer because it is a strong fit for network services: easy cross-compilation, static binaries, straightforward concurrency, and a rich ecosystem of modules. That means
golang.org/x/net/html can appear in places where the primary application does not advertise itself as an HTML processor. A service may only need a page title, a few links, or a sanitized fragment, but it still has to parse the document to get there.This is where “arbitrary HTML” becomes a warning label. If the service fetches URLs submitted by users, accepts rich text from external accounts, processes inbound email, or crawls partner content, the parser is effectively reachable by attackers. The exploit path may be indirect, but indirect does not mean implausible.
The rise of AI and automation makes the exposure larger. Retrieval systems, knowledge-base importers, support bots, and internal search tools increasingly ingest web pages and HTML-rich documents at scale. These systems often run behind authentication, which can make teams feel safe, but many of them accept content from semi-trusted sources. A parser that burns CPU on malicious markup can turn a convenient ingestion job into a denial-of-service lever.
The Fix Is Simple; Finding Every Copy Is Not
The upstream remediation path is straightforward: updategolang.org/x/net to version 0.55.0 or later and rebuild affected software. For a developer maintaining a small Go service, that may be a quick go get, test run, and deployment. For an enterprise, the work is less elegant.Modern organizations do not merely have source repositories. They have built artifacts, containers, vendored dependencies, forked modules, CI caches, old release branches, appliance images, developer utilities, and third-party binaries. A vulnerable module version in
go.mod is easy to spot. The same code compiled into a static executable with no software bill of materials is harder.Go’s static binary model is a gift to deployment and a headache for forensic dependency management. A single executable can carry all the relevant library code inside it, with no shared DLL sitting on disk to patch centrally. That simplicity is one reason Go services are so portable. It is also why vulnerability response must happen at build time, not by replacing a file in
System32.On Windows fleets, this distinction is particularly important because administrators are used to central patching workflows. WSUS, Microsoft Intune, Configuration Manager, Defender vulnerability signals, and vendor update channels can cover a great deal. They cannot automatically upgrade an internal Go service whose dependencies were frozen in a build pipeline six months ago.
The mature response is inventory first, remediation second. Teams need to identify applications that depend on
golang.org/x/net before version 0.55.0, then determine whether those applications call the affected HTML parsing functions on untrusted or attacker-influenced content. Not every vulnerable dependency is exploitable in a given deployment. But pretending unused vulnerable code cannot exist is how small advisories become embarrassing outages.The Windows Impact Is Indirect, Which Makes It Easier to Miss
CVE-2026-25680 is not a Windows vulnerability in the sense of a kernel bug, an Office flaw, or an Exchange Server emergency. There is no reason to expect a Windows cumulative update alone to remediate every instance of it. The Windows impact comes from what Windows runs.That includes internal web services built in Go and deployed as Windows services. It includes containerized workloads hosted on Windows nodes. It includes cross-platform agents, developer tools, observability collectors, security scanners, and vendor products whose internals are not obvious from their user interfaces. If those tools parse HTML from untrusted sources, the operating system underneath is mostly incidental.
This indirectness creates a gap between ownership models. The Windows admin may own the server. The application team may own the code. A vendor may own the binary. The security team may own the vulnerability report. The cloud team may own the deployment platform. Availability risk falls through those seams unless somebody is accountable for the full runtime stack.
For sysadmins, the immediate operational signal is CPU behavior. A vulnerable parser attack may look like sudden CPU saturation, thread starvation, queue buildup, increased request latency, health-check failures, or autoscaling churn. It may not produce a neat crash dump or a clear security log entry. If a service processes HTML and suddenly consumes abnormal CPU while handling odd-looking content, this CVE belongs in the hypothesis list.
For developers, the signal is dependency reachability. If code paths parse remote pages, uploaded HTML, email bodies, chat messages, issue descriptions, CMS exports, or scraped fragments, the parser is reachable. If those code paths run synchronously on request-handling workers, the risk is higher. If they run in bounded background jobs with strict timeouts and concurrency limits, the risk is lower but not gone.
Medium Severity Does Not Mean Medium Urgency
Security programs often translate severity into scheduling: critical today, high this week, medium later, low eventually. That model breaks down when the vulnerable component sits on a business-critical ingestion path. A medium CVSS availability bug can deserve urgent remediation if it threatens the service that customers, employees, or automation depend on every hour.The attack complexity is low enough to take seriously, but user interaction is part of the scoring because an application generally has to parse supplied content. That does not necessarily mean a human must click a malicious page in the browser. In server-side systems, “interaction” can be an application accepting a submitted URL, processing an uploaded file, importing a feed, or fetching content on behalf of a user.
This nuance matters because many teams wrongly equate user interaction with phishing. Here, the interaction may be architectural. If the business logic is designed to consume untrusted HTML, then the application is cooperating with the attacker by design.
The absence of confidentiality and integrity impact should also not lull infrastructure teams. Availability is a first-class security property for authentication portals, monitoring systems, support platforms, billing services, and deployment pipelines. A parser bug that knocks out a customer-facing preview service is annoying. The same class of bug affecting a security gateway or automation controller can have wider consequences.
There is also a compounding effect. CPU exhaustion in one service can cascade into retry storms, queue growth, autoscaling costs, database pressure, and noisy alerts that obscure other incidents. Denial of service rarely stays perfectly contained in a distributed system. It finds the dependencies that were sized for normal behavior.
The Real Mitigation Is a Boundary Around Parsing
Updating togolang.org/x/net 0.55.0 or later is the necessary fix, but it should not be the only lesson. Any system that parses attacker-influenced documents should treat parsing as a dangerous operation with budgets. CPU time, memory, input size, recursion depth, queue length, and concurrency all need limits.That is not because Go is uniquely unsafe. It is because parsers are complex by nature. They translate hostile ambiguity into structured data. HTML is especially messy because real-world markup is malformed, nested, duplicated, truncated, and full of historical browser compatibility traps. An attacker does not need a buffer overflow if an algorithmic corner case gives them a cheaper path to exhaustion.
The safest architecture isolates parsing work from request-critical paths. A web request should not be able to monopolize a worker indefinitely because it submitted a malicious fragment. Parsing jobs should run with context deadlines, input caps, worker pools, and back-pressure. If the system must fetch remote HTML, it should also enforce response size limits and fetch timeouts before the parser ever sees the bytes.
Sanitization is not a complete answer if it relies on the same vulnerable parsing path. Teams sometimes say “we sanitize HTML before parsing it,” but sanitizers usually parse too. The mitigation has to happen outside or before the expensive operation: limit what is accepted, cap how much is processed, and constrain the resources available to the parser.
For Windows operators, service-level guardrails still matter. Process isolation, CPU quotas in containers, job objects, service recovery policies, health probes, and rate limiting at reverse proxies can reduce blast radius. These controls do not replace the library update, but they can turn a total outage into a degraded queue and a page to the on-call engineer instead of a customer-visible collapse.
Dependency Management Has Become an Availability Discipline
The modern software supply chain conversation often centers on malicious packages and credential theft. CVE-2026-25680 is more mundane and therefore more representative. A legitimate, widely used module has a performance vulnerability in a specific parser. The fix exists. The challenge is whether organizations can discover, prioritize, and redeploy affected software quickly enough.This is where software bills of materials become practical rather than bureaucratic. If an organization can answer which deployed binaries include
golang.org/x/net and which versions they contain, the advisory is manageable. If the answer requires Slack archaeology, tribal memory, and guessing based on repository names, the organization is not managing software risk; it is hoping.Go teams have useful tooling, including module metadata, vulnerability scanning, and reproducible build practices. But tools only help when wired into release workflows. A scan that runs in a developer laptop is not the same as a policy gate in CI. A dependency alert in a repository is not the same as proof that production has been rebuilt and redeployed.
Vendor management belongs in the same conversation. Many Windows environments run commercial tools that include Go components. Customers may not see the dependency directly, but they still inherit its risk. Procurement and security teams should be asking vendors not only whether they are affected, but which product versions contain the fix and whether mitigations are available before an upgrade window.
The hard part is not writing the patch command. It is maintaining enough visibility that the patch command can be aimed at the right targets. CVE-2026-25680 rewards organizations that already know what they are running.
Go’s Strengths Do Not Exempt It From Boring Security Work
Go has earned its place in infrastructure because it makes many things simple: deployment, concurrency, readability, and performance. Those strengths sometimes create a false sense that Go services are operationally self-contained and security-light compared with older stacks. This vulnerability is a useful corrective.Memory safety reduces entire categories of bugs, but it does not eliminate algorithmic complexity. Static binaries reduce deployment friction, but they do not remove the need to rebuild after dependency fixes. A small service written in a clean language can still expose a high-value endpoint to malformed input and fall over under pressure.
The Go ecosystem’s response model is relatively healthy: publish advisories, identify affected symbols, mark fixed versions, and provide references to changes. That transparency helps defenders. But no language ecosystem can reach into every enterprise and redeploy old binaries.
This is especially relevant for Windows-heavy organizations that adopted Go quietly. The first wave of Go in many enterprises came through infrastructure tools rather than line-of-business applications: agents, CLIs, exporters, proxies, schedulers, and automation services. Those tools may not be owned by traditional application teams, and their dependency posture may be less visible.
The result is a new kind of patch Tuesday that does not arrive on Tuesday. Language ecosystems, container registries, GitHub advisories, vendor bulletins, and Microsoft security listings now all feed the same remediation calendar. Administrators who treat only operating-system patches as real patches are fighting the last decade’s war.
This Advisory Is a Small Test of a Bigger Patch Habit
The concrete action items are not exotic, which is precisely why this CVE is a useful test of operational discipline. If a team cannot handle a contained Go dependency DoS with a known fixed version, it will struggle with the messier supply-chain incidents that have less tidy boundaries.- Inventory Go applications, containers, agents, and vendor tools that include
golang.org/x/netbefore version 0.55.0. - Prioritize systems that parse user-supplied, externally fetched, uploaded, emailed, or scraped HTML.
- Rebuild and redeploy affected internally maintained software with
golang.org/x/netversion 0.55.0 or later. - Ask vendors for fixed product versions when the dependency is embedded in commercial software or closed binaries.
- Add input size limits, parsing timeouts, worker isolation, and rate limits around HTML ingestion paths even after patching.
- Monitor for abnormal CPU saturation, parser-heavy request patterns, queue buildup, and repeated malformed HTML submissions.
The Quiet CVEs Are Where Resilience Is Proven
CVE-2026-25680 will not be remembered like a wormable Windows flaw or a headline-grabbing zero-day in a browser. It is narrower, quieter, and less dramatic: a parser can be made to spend too much CPU on hostile HTML, and the fixed path is to update a Go module. But that is exactly why it belongs on the radar of serious IT teams. The next outage may not start with an exploit kit or a stolen password; it may start with a dependency nobody remembered was parsing the web on the organization’s behalf, and the organizations that fare best will be the ones that treat those invisible parsers as production infrastructure rather than incidental code.References
- Primary source: MSRC
Published: 2026-06-18T01:40:25-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: pkg.go.dev
- Related coverage: cve.imfht.com
golang.org/x/net/html Vulnerabilities (10 CVEs) | Shenlong CVE Platform
All 10 CVE vulnerabilities found in golang.org/x/net/html, with AI-generated Chinese analysis, references, and POCs.
cve.imfht.com
- Related coverage: test.osv.dev
OSV - Open Source Vulnerabilities
Comprehensive vulnerability database for your open source projects and dependencies.
test.osv.dev
