Bump python from 3.15.0a8-slim to 3.15.0b1-slim

[dependabot]

Bumps python from 3.15.0a8-slim to 3.15.0b1-slim.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

✅⚠️MegaLinter analysis: Success with warnings

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ ACTION	actionlint	3		0	0	0.02s
✅ DOCKERFILE	hadolint	1		0	0	0.09s
✅ JSON	jsonlint	2		0	0	0.34s
✅ JSON	prettier	2	0	0	0	0.31s
✅ JSON	v8r	2		0	0	2.63s
✅ MARKDOWN	markdownlint	1	0	0	0	0.73s
✅ MARKDOWN	markdown-table-formatter	1	0	0	0	0.18s
✅ PYTHON	bandit	1		0	0	2.04s
✅ PYTHON	black	1	0	0	0	1.49s
✅ PYTHON	flake8	1		0	0	0.65s
✅ PYTHON	isort	1	0	0	0	0.21s
✅ PYTHON	mypy	1		0	0	3.1s
✅ PYTHON	pylint	1		0	0	4.9s
✅ PYTHON	pyright	1		0	0	2.57s
✅ PYTHON	ruff	1	0	0	0	0.03s
✅ REPOSITORY	checkov	yes		no	no	21.29s
✅ REPOSITORY	gitleaks	yes		no	no	0.28s
✅ REPOSITORY	git_diff	yes		no	no	0.0s
✅ REPOSITORY	grype	yes		no	no	45.11s
✅ REPOSITORY	secretlint	yes		no	no	1.27s
✅ REPOSITORY	syft	yes		no	no	2.03s
⚠️ REPOSITORY	trivy	yes		2	no	10.57s
✅ REPOSITORY	trivy-sbom	yes		no	no	0.16s
✅ REPOSITORY	trufflehog	yes		no	no	4.01s
✅ SPELL	lychee	10		0	0	0.69s
✅ YAML	prettier	6	0	0	0	0.49s
✅ YAML	v8r	6		0	0	6.96s
✅ YAML	yamllint	6		0	0	0.48s

Detailed Issues

⚠️ REPOSITORY / trivy - 2 errors

error: Package: urllib3
Installed Version: 2.6.3
Vulnerability CVE-2026-44431
Severity: HIGH
Fixed Version: 2.7.0
Link: [CVE-2026-44431](https://avd.aquasec.com/nvd/cve-2026-44431)
    ┌─ requirements.txt:336:1
    │
336 │ urllib3==2.6.3 \
    │ ^
    │
    = urllib3: Sensitive headers forwarded across origins in proxied low-level redirects
    = ### Impact
      
      When following cross-origin redirects for requests made using urllib3’s high-level APIs, such as `urllib3.request()`, `PoolManager.request()`, and `ProxyManager.request()`, sensitive headers — `Authorization`, `Cookie`, and `Proxy-Authorization` (defined in `Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT`) — are stripped by default, as expected.
      
      However, cross-origin redirects followed from the low-level API via `ProxyManager.connection_from_url().urlopen(..., assert_same_host=False)` still forward these sensitive headers.
      
      ### Affected usage
      
      Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected if they allow cross-origin redirects while making requests through `HTTPConnection.urlopen()` instances created via `ProxyManager.connection_from_url()`.
      
      ### Remediation
      
      Upgrade to urllib3 version 2.7.0 or later, in which sensitive headers are stripped from redirects followed by `HTTPConnection`.
      
      If upgrading is not immediately possible, avoid using this low-level redirect flow for cross-origin redirects. If appropriate for your use case, switch to `ProxyManager.request()`.

error: Package: urllib3
Installed Version: 2.6.3
Vulnerability CVE-2026-44432
Severity: HIGH
Fixed Version: 2.7.0
Link: [CVE-2026-44432](https://avd.aquasec.com/nvd/cve-2026-44432)
    ┌─ requirements.txt:336:1
    │
336 │ urllib3==2.6.3 \
    │ ^
    │
    = urllib3: Decompression-bomb safeguards bypassed in parts of the streaming API
    = ### Impact
      
      urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.
      
      urllib3 can perform decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.
      
      However, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases:
      1. During the second `HTTPResponse.read(amt=N)` call when the response was decompressed using the official [Brotli](https://pypi.org/project/brotli/) library.
      2. When `HTTPResponse.drain_conn()` was called after the response had been read and decompressed partially (compression algorithm did not matter here).
      
      These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side.
      
      
      ### Affected usages
      
      Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:
      
      1. A response encoded with `br` is read incrementally with at least two `HTTPResponse.read(amt=N)` or `HTTPResponse.stream(amt=N)` calls while using the official [Brotli](https://pypi.org/project/brotli/) library.
      2. `HTTPResponse.drain_conn()` is called after response decompression has already started.
      
      
      ### Remediation
      
      Upgrade to at least urllib3 version 2.7.0 in which the library:
      1. Is more efficient for reads with Brotli.
      2. Always skips decompression for `HTTPResponse.drain_conn()`.
      
      If upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases:
      1. For the Brotli-specific issue only, switch from [brotli](https://pypi.org/project/brotli/) to [brotlicffi](https://pypi.org/project/brotlicffi/) until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396.
      2. If your code explicitly calls `HTTPResponse.drain_conn()`, call `HTTPResponse.close()` instead when connection reuse is not important.
      
      
      ### Credits
      
      The Brotli-specific issue was reported by @kimkou2024.
      `HTTPResponse.drain_conn()` inefficiency was reported by @Cycloctane.

error: 2 errors emitted

See detailed reports in MegaLinter artifacts

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

• Documentation: Custom Flavors
• Command: npx mega-linter-runner@9.4.0 --custom-flavor-setup --custom-flavor-linters PYTHON_PYLINT,PYTHON_BLACK,PYTHON_FLAKE8,PYTHON_ISORT,PYTHON_BANDIT,PYTHON_MYPY,PYTHON_PYRIGHT,PYTHON_RUFF,ACTION_ACTIONLINT,DOCKERFILE_HADOLINT,JSON_JSONLINT,JSON_V8R,JSON_PRETTIER,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_GITLEAKS,REPOSITORY_GRYPE,REPOSITORY_SECRETLINT,REPOSITORY_SYFT,REPOSITORY_TRIVY,REPOSITORY_TRIVY_SBOM,REPOSITORY_TRUFFLEHOG,SPELL_LYCHEE,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

Show us your support by starring ⭐ the repository