chore(deps): refresh rpm lockfiles [SECURITY]

[red-hat-konflux]

This PR contains the following updates:

File rpms.in.yaml:

Package	Change
gcc-toolset-14-gcc	14.2.1-10.el8_10 -> 14.2.1-11.el8_10
gcc-toolset-14-gcc-c++	14.2.1-10.el8_10 -> 14.2.1-11.el8_10
gcc-toolset-14-libstdc++-devel	14.2.1-10.el8_10 -> 14.2.1-11.el8_10
python3.12	3.12.12-1.el8_10 -> 3.12.12-2.el8_10
python3.12-libs	3.12.12-1.el8_10 -> 3.12.12-2.el8_10
brotli	1.0.6-3.el8 -> 1.0.6-4.el8_10
libselinux	2.9-10.el8_10 -> 2.9-11.el8_10
libselinux-devel	2.9-10.el8_10 -> 2.9-11.el8_10
libselinux-utils	2.9-10.el8_10 -> 2.9-11.el8_10
python3-libselinux	2.9-10.el8_10 -> 2.9-11.el8_10
s390utils-base	2:2.29.0-3.el8_10.3 -> 2:2.29.0-3.el8_10.4
s390utils-core	2:2.29.0-3.el8_10.3 -> 2:2.29.0-3.el8_10.4
s390utils-se-data	2:2.29.0-3.el8_10.3 -> 2:2.29.0-3.el8_10.4

---

cpython: python: Python zipfile End of Central Directory (EOCD) Locator record offset not checked

CVE-2025-8291

More information

Details

The 'zipfile' module would not check the validity of the ZIP64 End of
Central Directory (EOCD) Locator record offset value would not be used to
locate the ZIP64 EOCD record, instead the ZIP64 EOCD record would be
assumed to be the previous record in the ZIP archive. This could be abused
to create ZIP archives that are handled differently by the 'zipfile' module
compared to other ZIP implementations.

Remediation maintains this behavior, but checks that the offset specified
in the ZIP64 EOCD Locator record matches the expected value.

Severity

Moderate

References

• https://access.redhat.com/security/cve/CVE-2025-8291
• https://bugzilla.redhat.com/show_bug.cgi?id=2402342
• https://www.cve.org/CVERecord?id=CVE-2025-8291
• https://nvd.nist.gov/vuln/detail/CVE-2025-8291
• https://github.com/python/cpython/commit/162997bb70e067668c039700141770687bc8f267
• https://github.com/python/cpython/commit/333d4a6f4967d3ace91492a39ededbcf3faa76a6
• https://github.com/python/cpython/issues/139700
• https://github.com/python/cpython/pull/139702
• https://mail.python.org/archives/list/security-announce@python.org/thread/QECOPWMTH4VPPJAXAH2BGTA4XADOP62G/

---

cpython: Excessive read buffering DoS in http.client

CVE-2025-13836

More information

Details

A flaw was found in the http.client module in the Python standard library. When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This issue allows a malicious server to cause the client to read large amounts of data into memory, potentially causing memory allocations errors, swapping, out-of-memory conditions or even system freezes.

Severity

Moderate

References

• https://access.redhat.com/security/cve/CVE-2025-13836
• https://bugzilla.redhat.com/show_bug.cgi?id=2418078
• https://www.cve.org/CVERecord?id=CVE-2025-13836
• https://nvd.nist.gov/vuln/detail/CVE-2025-13836
• https://github.com/python/cpython/issues/119451
• https://github.com/python/cpython/pull/119454

---

Scrapy: python-scrapy: brotli: Python brotli decompression bomb DoS

CVE-2025-6176

More information

Details

Scrapy are vulnerable to a denial of service (DoS) attack due to a flaw in its brotli decompression implementation. The protection mechanism against decompression bombs fails to mitigate the brotli variant, allowing remote servers to crash clients with less than 80GB of available memory. This occurs because brotli can achieve extremely high compression ratios for zero-filled data, leading to excessive memory consumption during decompression.

Severity

Important

References

• https://access.redhat.com/security/cve/CVE-2025-6176
• https://bugzilla.redhat.com/show_bug.cgi?id=2408762
• https://www.cve.org/CVERecord?id=CVE-2025-6176
• https://nvd.nist.gov/vuln/detail/CVE-2025-6176
• https://huntr.com/bounties/2c26a886-5984-47ee-a421-0d5fe1344eb0

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Configuration

📅 Schedule: Branch creation - "" in timezone Etc/UTC, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

To execute skipped test pipelines write comment /ok-to-test.

---

Documentation

Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.

[rhacs-bot]

Auto-approved by automation.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 27.61%. Comparing base (9810a51) to head (73ee9d6).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@              Coverage Diff              @@
##           release-3.23    #2896   +/-   ##
=============================================
  Coverage         27.61%   27.61%           
=============================================
  Files                96       96           
  Lines              5424     5424           
  Branches           2523     2523           
=============================================
  Hits               1498     1498           
  Misses             3214     3214           
  Partials            712      712           

Flag	Coverage Δ
collector-unit-tests	27.61% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

/retest collector-on-push

[github-actions]

/retest collector-on-push

[github-actions]

/retest collector-on-push

[red-hat-konflux]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.