Search: com.ar

## Summary The `MethodOverride` middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When `MethodOverride` is registered before `CSRF` in the post-routing middleware chain (`e.Use()`), it rewrites the request method to a safe method before `CSRF` evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern `Sec-Fetch-Site` protection path are bypassed simultaneously. ## Affected Component - `middleware/method_override.go` — `MethodOverrideConfig.ToMiddleware()` (lines 55–71): no whitelist on the override target method - `middleware/csrf.go` — `CSRFConfig.ToMiddleware()` (lines 188–189): safe-method bypass branch reads the already-rewritten method - `middleware/csrf.go` — `checkSecFetchSiteRequest()` (line 283): `Sec-Fetch-Site` safe check also reads the rewritten method ## Description ### MethodOverride accepts safe methods as override targets `MethodOverrideConfig.ToMiddleware()` (`method_override.go:55-71`) restricts the **source** method (only POST requests are overrideable) but applies no whitelist to the **target**: ```go // method_override.go:61-67 req := c.Request() if req.Method == http.MethodPost { m := config.Getter(c) if m != "" { req.Method = m // ← any non-empty string accepted, including "GET" } } ``` The docstring's security claim — "For security reasons, only POST method can be overridden" — refers only to the source-method restriction. There is no guard preventing POST from being rewritten to `GET`, `HEAD`, `OPTIONS`, or `TRACE`. The test suite (`method_override_test.go`) only tests POST→DELETE and POST→PUT; POST→GET is never tested or blocked. ### CSRF safe-method branch reads the already-rewritten method `CSRFConfig.ToMiddleware()` (`csrf.go:188-189`) makes its validation decision based on `c.Request().Method` at the time it runs: ```go // csrf.go:188-189 switch c.Request().Method { case http.MethodGet, http.MethodHead, http.MethodOptions, http.MethodTrace: // skip validation — no token check default: // validate CSRF token ``` If MethodOverride has already run and set `req.Method = "GET"`, this `switch` falls into the skip branch regardless of the original HTTP method or what handler was matched. The `Sec-Fetch-Site`-based path in `checkSecFetchSiteRequest()` (`csrf.go:283`) is identically vulnerable: ```go // csrf.go:283 isSafe := slices.Contains(safeMethods, c.Request().Method) ``` With `req.Method = "GET"` (already rewritten), `isSafe = true` and the function returns `true` — the request is allowed even when `Sec-Fetch-Site` is `cross-site`. **Both** CSRF protection paths are bypassed in a single step. ### Execution chain In `echo.go:700`, routing and middleware wrapping are performed in one step: ```go h = applyMiddleware(e.router.Route(c), e.middleware...) ``` 1. `e.router.Route(c)` evaluates with `req.Method = "POST"` → matches and binds the POST `/transfer` handler 2. `applyMiddleware` wraps it: `MethodOverride → CSRF → postHandler` At request execution time: 3. **MethodOverride** runs: `req.Method == "POST"` → reads form field `_method` = `"GET"` → `req.Method = "GET"` → calls `next` 4. **CSRF** runs: `c.Request().Method` = `"GET"` → `case http.MethodGet` → **skips token validation** → calls `next` 5. **postHandler** runs (the handler matched in step 1 — the original POST `/transfer` state-change handler) The state-changing handler executes with no CSRF token validation and with no `Sec-Fetch-Site` check. ### The missing target-method whitelist is the root cause The legitimate use case for MethodOverride is allowing HTML forms (which only support GET/POST) to send PUT, DELETE, or PATCH requests. There is no legitimate scenario in which an HTML form needs to rewrite POST to GET — that can always be expressed as an ordinary GET request. Allowing POST→GET (and HEAD/OPTIONS/TRACE) serves no valid purpose and is inherently dangerous when any safe-method-aware security middleware (CSRF, logging, audit) appears downstream. ## Proof of Concept ```go package main import ( "net/http" echo "github.com/labstack/echo/v5" "github.com/labstack/echo/v5/middleware" ) func main() { e := echo.New() // MethodOverride before CSRF — both in e.Use() (post-routing) e.Use(middleware.MethodOverrideWithConfig(middleware.MethodOverrideConfig{ Getter: middleware.MethodFromForm("_method"), })) e.Use(middleware.CSRF()) e.POST("/transfer", func(c *echo.Context) error { return c.String(http.StatusOK, "transfer executed") }) e.Logger.Fatal(e.Start(":18080")) } ``` ```bash # Baseline — CSRF correctly blocks a POST without a valid token curl -i -X POST 'http://127.0.0.1:18080/transfer' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data 'amount

## Summary The Echo proxy middleware (`middleware/proxy.go`) preserves an incoming `X-Real-IP` header verbatim and forwards it to the upstream service when `Echo#IPExtractor` is not configured — which is the default. Because any HTTP client can supply an arbitrary `X-Real-IP` value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction. ## Affected Component - `middleware/proxy.go` — `ProxyConfig.ToMiddleware()`, header-rewriting block (lines 351–355) ## Description ### The header-preservation condition passes spoofed values to upstream `ProxyConfig.ToMiddleware()` (`proxy.go:338-405`) prepares forwarding headers before dispatching each request. The `X-Real-IP` rewrite logic at lines 351-355 reads: ```go // proxy.go:351-355 // Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. // However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor. if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil { req.Header.Set(echo.HeaderXRealIP, c.RealIP()) } ``` The condition is `TRUE` (and therefore overwrites the header with a derived value) only when: - The header is absent — `req.Header.Get(echo.HeaderXRealIP) == ""`; **or** - `IPExtractor` is explicitly configured — `c.Echo().IPExtractor != nil` The condition is `FALSE` — and the header is left **unchanged** — when the request arrives with an `X-Real-IP` header already set **and** `IPExtractor` is `nil`. Because `Echo.New()` leaves `IPExtractor` as `nil`, this is the out-of-the-box behaviour for every application that uses `Proxy()` or `ProxyWithConfig()` without extra configuration. An attacker who sets `X-Real-IP` to any value causes Echo to forward exactly that value to the upstream, with no modification or validation. ### The comment in the source code confirms intent and the security gap The inline comment at line 351-352 explicitly states: > "Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor." The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the `Proxy()` or `ProxyWithConfig()` documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration. This is structurally identical to the documented insecurity in `ip.go:27`: > "Note: if you don't set `Echo#IPExtractor` explicitly, Echo fallback to legacy behavior, which is not a good choice." ### Full execution chain 1. Attacker sends `GET /api/admin` to the Echo proxy with header `X-Real-IP: 203.0.113.1` (a trusted corporate IP) 2. `ToMiddleware()` evaluates the guard at line 353: header is present (`!= ""`), `IPExtractor` is `nil` → condition is `FALSE` 3. `req.Header.Set` is **not** called; the upstream request carries the original, attacker-supplied `X-Real-IP: 203.0.113.1` 4. Upstream service checks `X-Real-IP` against its IP allowlist → finds `203.0.113.1` → grants access 5. Attacker reaches an endpoint that should be restricted to the corporate IP range Secondary impact path (audit poisoning): - All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against `203.0.113.1` rather than the real client IP, rendering audit trails and security analytics unreliable. ## Proof of Concept ```go package main import ( "fmt" "log" "net/http" echo "github.com/labstack/echo/v5" "github.com/labstack/echo/v5/middleware" ) func main() { // Upstream server: echoes back the X-Real-IP it received upstream := http.NewServeMux() upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP")) }) go http.ListenAndServe(":9000", upstream) // Echo proxy — IPExtractor deliberately NOT set (the default) e := echo.New() targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}} e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets))) log.Fatal(e.Start(":1323")) } ``` ```bash # Without spoofed header — upstream sees actual peer address curl http://127.0.0.1:1323/ # upstream sees X-Real-IP: 127.0.0.1 # With spoofed header — upstream sees attacker-supplied value curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/ # upstream sees X-Real-IP: 198.51.100.77 ``` The attacker-supplied IP `198.51.100.77` arrives at the upstream unchanged. ## Impact - Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in `X-Real-IP` - Upstream rate limiters that key on `X-Real-IP` are bypassable (same class as the Echo rate-limiter fi

## Summary The `/credentials/signurl` endpoint decides authorization from the client-supplied `X-Rucio-Account` HTTP header instead of the authenticated token's account. Any client holding **any** valid auth token (even a low-privilege account they legitimately own) can send `X-Rucio-Account: root` to pass the root-only permission check and have the Rucio server mint a presigned **read / write / delete** URL for an **arbitrary** object, signed with the RSE's stored S3 / GCS / Swift credentials. ## Details `SignURL.get()` takes the authorization principal from a request header and never uses the token-authenticated identity: ```python # lib/rucio/web/rest/flaskapi/v1/credentials.py account = request.headers.get('X-Rucio-Account', default=None) # L165 (attacker-controlled) ... result = get_signed_url(account, rse=rse, service=service, # L194 operation=operation, url=url, lifetime=lifetime, vo=vo) ``` The gateway then uses that header value as the `issuer` for the permission check: ```python # lib/rucio/gateway/credential.py auth_result = permission.has_permission(issuer=account, vo=vo, # L57 action='get_signed_url', kwargs=kwargs, ...) ``` and the permission function is root-only: ```python # lib/rucio/core/permission/generic.py def perm_get_signed_url(issuer, kwargs, session): return _is_root(issuer) # _is_root(x) -> x.external == 'root' ``` `InternalAccount('root', vo).external == 'root'` unconditionally, so the gate passes whenever the header is `root`. The endpoint is on `AuthenticatedBlueprint`, whose `before_request` hook validates the token and sets `request.environ['issuer']` **from the token** — but nothing ever compares `X-Rucio-Account` to it: ```python # lib/rucio/web/rest/flaskapi/v1/common.py (request_auth_env) flask.request.environ['issuer'] = auth.get('account') # L168 (the real account; unused by SignURL) ``` This is anomalous: every other authenticated handler derives the account from `request.environ['issuer']`; `credentials.py` is the only one that trusts the header. Additionally, `core.credential.get_signed_url` never checks that the supplied `url`'s host/bucket belongs to the target RSE, so even a legitimate `root` caller gets an arbitrary-object signing oracle. In multi-VO the VO is also read from the `X-Rucio-VO` header, allowing cross-tenant targeting. ## Proof of concept Request (any valid token + spoofed account): ``` GET /credentials/signurl?rse=<cloudRSE>&svc=s3&op=delete&url=https://victim-bucket.s3.amazonaws.com/important/dataset.root HTTP/1.1 X-Rucio-Auth-Token: <any valid token, even a low-privilege account> X-Rucio-Account: root Accept: application/octet-stream ``` Response: `200 OK` with a presigned DELETE URL the attacker replays directly against the storage backend. ## Impact A low-privilege Rucio user can read, overwrite, and delete arbitrary objects on any cloud-backed (S3/GCS/Swift) RSE using the server's stored credentials — enabling data exfiltration, tampering, and destruction, and cross-tenant access in multi-VO deployments. ## Credit Reported by seankohjs. Found via static analysis + manual verification.

## Summary With `SslMode` set to `VerifyCA` or `VerifyFull` with no configured CA certificate, an unvalidated TLS connection is treated as secure and a clear-text password can be sent before the certificate is checked. This can occur when relying on the password to validate a self-signed cert, e.g., MariaDB's [zero-configuration TLS](https://mariadb.com/docs/server/security/encryption/data-in-transit-encryption/zero-configuration-ssl). ## Impact An attacker who can deploy a man-in-the-middle MySQL proxy presenting any self-signed certificate can capture the plaintext database password of a client that: - uses `SslMode = VerifyCA` or `VerifyFull`, and - does not use the `SslCa` connection string option, and - uses a non-empty password. The attacker completes the TLS handshake with its own cert, requests a clear-text password authentication scheme (`mysql_clear_password`, or forces the `caching_sha2_password`/`sha256_password` clear-text fallback), and receives the password before the fingerprint check rejects the connection, defeating the man-in-the-middle protection `VerifyFull` is expected to provide. Not affected: a configured CA (`SslCa`), CA-validated TLS, local connections (Unix socket / loopback), or empty passwords. Using `SslMode` set to `Preferred` or `Required` is out of scope (this is documented as not authenticating the server). ## Workarounds Provide `SslCa` with `VerifyCA`/`VerifyFull`, use a local/Unix-socket connection, or avoid clear-text authentication. ## References - https://mariadb.org/mission-impossible-zero-configuration-ssl/

A CSV formula injection vulnerability exists in the registrations export feature of the Joomla extension iCagenda versions 3.5.0 through 4.0.16. This vulnerability allows malicious formulas to be injected into exported CSV files, potentially leading to unintended execution when the CSV is opened in spreadsheet software.

The Rich Showcase for Google Reviews plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 7.1.6 This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with contributor-level access and above, to retrieve the plugin's 127-character site-wide grw_auth_code authentication secret and use it to impersonate the WordPress site to the RichPlugins backend service at app.richplugins.com.

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.16.74. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:89715 Security Fix(es): * net/http/internal/http2: golang: golang.org/x/net: Go HTTP/2: Denial of Service via malformed SETTINGS_MAX_FRAME_SIZE frame (CVE-2026-33814) * cri-o: cri-o: Sandbox state poisoning via pod annotations may expose runtime socket (CVE-2026-62146) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.16 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html-single/updating_clusters/index#updating-cluster-cli.

Private keys for eight eMudhra intermediate CA certificates have been compromised https://emudhra.we-have-a-problem.com/ , which impacts certificate trust for outbound network request features of HCL Notes Client.  An unauthenticated network attacker could spoof server certificates to execute a man in the middle (MITM) attack, enabling them to intercept and/or modify the content of outbound TLS connections.

Private keys for eight eMudhra intermediate CA certificates have been compromised https://emudhra.we-have-a-problem.com/ , which impacts certificate trust for outbound network request features of HCL Domino Server.  An unauthenticated network attacker could spoof server certificates to execute a man in the middle (MITM) attack, enabling them to intercept and/or modify the content of outbound TLS connections.

A vulnerability in github.com/klauspost/compress/zstd versions prior to 1.20.2 causes a panic due to an out-of-range slice index when decompressing crafted two-block zstd frames. The flaw arises from improper handling of Huffman-weight tables in the FSE decoder, leading to reuse of stale state and an invalid decode table. This can crash any program decompressing untrusted zstd input. The issue is fixed in version 1.20.2.

A vulnerability in github.com/eclipse-keypont/crypto11/v2 versions from 2.0.0-rc3 through 2.0.0-rc8 allows an attacker to compromise the confidentiality of shared secrets. The ML-KEM key-pair lookup functions do not verify that the public key matches the private key, enabling an attacker who can open an unauthenticated session and plant a public key object with victim identifiers to receive shared secrets intended for the victim. Versions prior to 2.0.0-rc3 and after 2.0.0-rc8, as well as v1 module paths, are not affected.

CVE-2026-102800 is a high-severity stored cross-site scripting (XSS) vulnerability in the DJ-HelpfulArticles extension for Joomla versions 1.0.0 through 1.2.0. The vulnerability arises from an unauthenticated voting widget that accepts a client-supplied 'ip' field via AJAX without proper output escaping. This field is stored and later rendered in the Joomla administrator backend without HTML escaping, enabling stored XSS attacks. The lack of CSRF tokens and rate limiting exacerbates the risk by allowing repeated exploitation.

The push endpoint of a Vaadin application that uses server push reflects the request Origin into the Access-Control-Allow-Origin response header and allows credentials, because Flow configures Atmosphere with DROP_ACCESS_CONTROL_ALLOW_ORIGIN_HEADER set to false and its CorsInterceptor then echoes whatever Origin the request carries. A page on any origin can therefore make a cross origin request to that endpoint with the user's cookies and read the response, although reading anything useful also requires the push identifier of that session. Applications that do not use @Push are not affected, and neither is the WebSocket transport. The behaviour was introduced in January 2015 and is present in every Flow release and in Vaadin Framework from 7.1.0, which is when push was added. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin 14.14.0 - 14.14.7 Vaadin 23.6.0 - 23.6.16 Vaadin 24.4.0 - 24.4.25 Vaadin 24.5.0 - 24.5.15 Vaadin 24.6.0 - 24.6.13 Vaadin 24.7.0 - 24.7.16 Vaadin 24.8.0 - 24.8.17 Vaadin 24.9.0 - 24.9.23 Vaadin 24.10.0 - 24.10.11 Vaadin 25.0.0 - 25.0.13 Vaadin 25.1.0 - 25.1.13 Vaadin 25.2.0 - 25.2.10 Vaadin 25.3.0 - 25.3.2 Vaadin Framework 7.1.0 - 7.7.54 Vaadin Framework 8.0.0 - 8.32.1 Mitigation Upgrade to 14.14.8 Upgrade to 23.6.17 Upgrade to 24.4.26 Upgrade to 24.7.17 Upgrade to 24.7.17 Upgrade to 24.7.17 Upgrade to 24.9.24 Upgrade to 24.9.24 Upgrade to 24.10.12 Upgrade to 25.2.11 Upgrade to 25.2.11 Upgrade to 25.2.11 Upgrade to 25.3.3 Upgrade to 7.7.55 Upgrade to 8.32.2 Please note that Vaadin versions 10-13 and 15-22 are no longer supported and you should update either to the latest 14, 23, 24, 25 version. Artifacts under com.vaadin Maven coordinates / Vulnerable versions / Fixed version vaadin / 14.14.0 - 14.14.7 / >=14.14.8 vaadin / 23.6.0 - 23.6.16 / >=23.6.17 vaadin / 24.4.0 - 24.4.25 / >=24.4.26 vaadin / 24.5.0 - 24.5.15 / >=24.7.17 vaadin / 24.6.0 - 24.6.13 / >=24.7.17 vaadin / 24.7.0 - 24.7.16 / >=24.7.17 vaadin / 24.8.0 - 24.8.17 / >=24.9.24 vaadin / 24.9.0 - 24.9.23 / >=24.9.24 vaadin / 24.10.0 - 24.10.11 / >=24.10.12 vaadin / 25.0.0 - 25.0.13 / >=25.2.11 vaadin / 25.1.0 - 25.1.13 / >=25.2.11 vaadin / 25.2.0 - 25.2.10 / >=25.2.11 vaadin / 25.3.0 - 25.3.2 / >=25.3.3 vaadin-core / 14.14.0 - 14.14.7 / >=14.14.8 vaadin-core / 23.6.0 - 23.6.16 / >=23.6.17 vaadin-core / 24.4.0 - 24.4.25 / >=24.4.26 vaadin-core / 24.5.0 - 24.5.15 / >=24.7.17 vaadin-core / 24.6.0 - 24.6.13 / >=24.7.17 vaadin-core / 24.7.0 - 24.7.16 / >=24.7.17 vaadin-core / 24.8.0 - 24.8.17 / >=24.9.24 vaadin-core / 24.9.0 - 24.9.23 / >=24.9.24 vaadin-core / 24.10.0 - 24.10.11 / >=24.10.12 vaadin-core / 25.0.0 - 25.0.13 / >=25.2.11 vaadin-core / 25.1.0 - 25.1.13 / >=25.2.11 vaadin-core / 25.2.0 - 25.2.10 / >=25.2.11 vaadin-core / 25.3.0 - 25.3.2 / >=25.3.3 flow-server / 2.13.0 - 2.13.7 / >=2.13.8 flow-server / 23.6.0 - 23.6.15 / >=23.6.16 flow-server / 24.4.0 - 24.4.18 / >=24.4.19 flow-server / 24.5.0 - 24.5.17 / >=24.7.17 flow-server / 24.6.0 - 24.6.14 / >=24.7.17 flow-server / 24.7.0 - 24.7.15 / >=24.7.16 flow-server / 24.8.0 - 24.8.16 / >=24.9.24 flow-server / 24.9.0 - 24.9.28 / >=24.9.29 flow-server / 24.10.0 - 24.10.14 / >=24.10.15 flow-server / 25.0.0 - 25.0.15 / >=25.2.11 flow-server / 25.1.0 - 25.1.18 / >=25.1.19 flow-server / 25.2.0 - 25.2.12 / >=25.2.13 flow-server / 25.3.0 - 25.3.3 / >=25.3.4 vaadin-server / 7.1.0 - 7.7.54 / >=7.7.55 vaadin-server / 8.0.0 - 8.32.1 / >=8.32.2 vaadin-server-mpr-jakarta / 7.7.36 - 7.7.54 / >=7.7.55 vaadin-server-mpr-jakarta / 8.18.0 - 8.32.1 / >=8.32.2

An unauthenticated SQL injection vulnerability exists in the Gridbox extension for Joomla versions 1.0.0 through 2.20.4.1. The flaw occurs on store product list pages where the sort-by URL parameter is improperly handled, allowing injection into the ORDER BY clause of a SQL query. This vulnerability is critical with a CVSS score of 9.3.

CVE-2026-102789 is a critical improper access control vulnerability in the Gridbox extension for Joomla by balbooa.com. Versions from 1.0.0 up to 2.20.4.1 are affected. The flaw exists because the EditorController::getBlogPosts() task lacks an authorization check that other controller tasks perform, allowing unauthorized users to invoke this function. This could lead to unauthorized access to blog post data or actions within the extension.

Red Hat issued a security advisory for osbuild-composer, a service that builds customized OS artifacts and uploads images to cloud environments. The update addresses multiple vulnerabilities including authorization bypass, cross-site scripting (XSS), arbitrary code execution via XSS, unauthorized information disclosure, and man-in-the-middle attacks via untrusted intermediate certificates. These vulnerabilities stem from components such as gRPC-Go, golang.org/x/net/html, github.com/labstack/echo, and crypto/x509. The update is rated as Important by Red Hat Product Security and applies to Red Hat Enterprise Linux 8.6 variants.

The general-purpose data-binding functionality and tree-model for Jackson Data Processor. It builds on core streaming parser/generator package, and uses Jackson Annotations for configuration. Security Fix(es): * com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: jackson-databind: CPU Denial of Service via unbounded numeric parsing (CVE-2026-68497) * com.fasterxml.jackson.core/jackson-databind: tools.jackson.core:jackson-databind: Jackson-databind: Denial of Service via quadratic forward-reference completion (CVE-2026-91777) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with repeated malformed cross-reference streams. ### Patches This has been fixed in [pypdf==6.21.2](https://github.com/py-pdf/pypdf/releases/tag/6.21.2). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#4240](https://github.com/py-pdf/pypdf/pull/4240). ### Notes This is a follow-up to https://github.com/py-pdf/pypdf/security/advisories/GHSA-55h5-xmcq-c37v, which had the side-effect of still loading the whole stream again despite the cache being present.