Security researchers have disclosed new flaws affecting QPACK, the header compression mechanism used by HTTP/3, that could allow a remote unauthenticated attacker to crash vulnerable web servers with a single connection. According to the disclosure, a small amount of crafted compressed header data can expand dramatically in server memory, creating a denial-of-service condition.

The reported issue matters for organisations that have enabled HTTP/3 on public-facing websites, APIs, SaaS platforms or reverse proxies. While the technical problem sits deep in modern web infrastructure, the business risk is straightforward: exposed services could become unavailable if vulnerable implementations are not patched or otherwise protected.

What happened

The disclosure describes QPACK-related flaws in HTTP/3 server handling that may let an attacker send a limited batch of compressed HTTP headers which expands to a much larger memory footprint on the server side. FoxIO said it released proof-of-concept code and reported that the amplification effect could be large enough to exhaust memory and crash default server setups.

Based on the available report, the attack does not require prior authentication. That increases the operational risk for internet-facing systems because any exposed endpoint using a vulnerable implementation could potentially be targeted remotely.

At the time of writing, businesses should distinguish between the reported class of attack and the specific products and versions affected. The source indicates a vulnerability disclosure and proof of concept, but each organisation will need to verify exposure against vendor advisories, software maintainers and infrastructure providers.

Why it matters for European businesses

HTTP/3 adoption has grown because it can improve web performance, resilience and user experience. Many businesses may have it enabled through CDNs, hosting stacks, reverse proxies or cloud platforms without treating it as a separate security review item. That creates a practical challenge: a protocol-level weakness can affect website availability even when application code is not at fault.

For European SMEs and digital businesses, the most immediate risk is service disruption. If a public website, checkout flow, customer portal or API becomes unavailable, the impact can extend to lost sales, interrupted operations and support overhead. For agencies and IT teams managing multiple client sites, the issue can also become a portfolio-wide exposure if the same infrastructure pattern is widely deployed.

This also has a compliance and resilience dimension. Organisations operating under stricter contractual security obligations or sector-specific requirements may need to show they are monitoring vulnerability disclosures, patching internet-facing systems and applying appropriate mitigation measures. Although the disclosure itself does not create a new legal obligation, downtime and weak patch governance can become relevant in broader cybersecurity risk management.

Who may be affected

• Businesses running their own web servers or reverse proxies with HTTP/3 enabled.
• E-commerce companies whose storefronts, checkout paths or APIs depend on HTTP/3-capable infrastructure.
• SaaS providers exposing customer-facing applications over modern web stacks.
• Digital agencies and managed service providers responsible for maintaining multiple client websites or platforms.
• IT and DevOps teams using CDN, edge or load-balancing services that may enable HTTP/3 by default or through platform settings.

Exposure will depend on implementation details. Some businesses may be protected if their providers have already patched affected components, rate-limited abusive traffic or disabled vulnerable behaviour. Others may not realise HTTP/3 is active in production, especially where it is enabled at the edge rather than on the origin server.

What companies should consider

• Check whether HTTP/3 is enabled on public-facing websites, APIs, gateways and edge services.
• Review vendor advisories and maintainer updates for web servers, reverse proxies, CDN services and hosting platforms to identify affected versions and available patches.
• Prioritise patching internet-facing infrastructure where a vulnerable implementation is confirmed or strongly suspected.
• Consider temporary mitigation such as disabling HTTP/3 where operationally acceptable until fixes are available or verified.
• Monitor memory usage and crash behaviour on exposed services to detect abnormal amplification patterns or denial-of-service attempts.
• Review edge protections including rate limiting, connection controls and DDoS protections that may reduce exploitability or operational impact.
• Document third-party dependencies so teams know whether responsibility sits with an internal platform team, a hosting provider or a CDN vendor.

For most businesses, this is not a reason to avoid HTTP/3 altogether. It is a reminder that performance-focused protocol upgrades can also introduce infrastructure-level risk. The practical response is to confirm exposure, follow vendor guidance and ensure public-facing web services have both patching discipline and fallback protections in place.