Search: h-w-g.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 container images for Red Hat OpenShift Container Platform 4.17.58. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHSA-2026:70585 Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/release_notes/

When the http:// stream wrapper follows a redirect it forwards the user-supplied Authorization, Cookie and Proxy-Authorization headers unchanged, even when the redirect target is a different host, a different port, or a downgrade from HTTPS to HTTP. A server that can steer a redirect therefore receives credentials that were only meant for the original origin. This is the same class of issue that libcurl fixed in 7.58.0 ( CVE-2018-1000007 https://github.com/advisories/GHSA-g7x2-hrfp-pv5f ).

A security flaw has been discovered in ZongXR SuperMarket 1.0.0.0. Affected by this issue is the function OrderController.deleteOrder of the file order/src/main/java/com/supermarket/order/controller/OrderController.java of the component Order Deletion Endpoint. Performing a manipulation of the argument orderId results in missing authentication. The attack is possible to be carried out 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.

A vulnerability was found in David-Crty databasement up to 1.7.1. This impacts the function https:/github.com/David-Crty/databasement/pull/511 of the file app/Http/Requests/Api/V1/RestoreRequest.php of the component database-servers API Endpoint. The manipulation of the argument schema_name results in path traversal. The attack may be launched remotely. A high complexity level is associated with this attack. The exploitability is said to be difficult. The exploit has been made public and could be used. Upgrading to version 1.7.2 will fix this issue. You should upgrade the affected component.

CVE-2026-92172 is a high-severity vulnerability in Meta Horizon OS prior to version 66.0.0.733.524. The flaw involves improper restriction of communication channels, allowing an application to receive a privileged PendingIntent with a com.oculus.horizon CallerIdentity via a broadcast receiver. This enables the application to impersonate the com.oculus.horizon package to any endpoint within the OS that relies on CallerIdentity authentication.

CVE-2026-92173 is a critical vulnerability in Meta Horizon OS prior to version 74.0.0.878.1682. It involves improper restriction of communication channels, allowing an arbitrary application with NotificationListenerService to receive a privileged PendingIntent containing a CallerIdentity from com.oculus.vrshell. This enables impersonation of the com.oculus.vrshell package and other packages signed with the same key for authentication within the OS.

Joomla Extension - joomcode.com - Unauthenticated SQL injection in read and write queries in JCTables 1.21.1 - The front-end CRUD API controller performs no Joomla token validation and no authentication check on any task. Table names, column names, and values are taken directly from request parameters and concatenated into SQL queries, allowing SQLi for reading and writing queries.

Joomla Extension - ordasoft.com - Unauthenticated Remote Code Execution in OrdaSoft Joomla CCK < 8.3.16 - site/uploader.php is reached through the component’s normal frontend routing (task=getContent), a task with no authentication or ACL check anywhere in the dispatch chain. The handler validates the uploaded file’s content with a real magic-byte MIME check, but the extension allow-list that would otherwise restrict the saved file’s extension was present in the source and commented out. The saved file’s extension was taken directly from the attacker-supplied filename with no validation, and the file was written to a path directly under the Joomla web root that is executed by the PHP handler. An image/PHP polyglot, a file whose header bytes satisfy the MIME check with PHP source appended after, passed the content check while carrying a .php extension of the attacker’s choosing.

The OpenShift File Integrity Operator v1.5.0 is now available. See the documentation for bug fix information: https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/security_and_compliance/file-integrity-operator

The npm package com.epi.e2e_test version 1.2.2 contains malicious code that executes automatically during installation. A preinstall script runs an index.js file which collects host-specific identifiers such as the home directory, hostname, username, DNS servers, current working directory, and the package.json contents. This data is then sent via HTTPS to a hardcoded external server (meta.brs.cx) without user consent. This behavior is indicative of reconnaissance activity commonly associated with dependency confusion or internal name attacks.

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 container images for Red Hat OpenShift Container Platform 4.19.49. There is no advisory for the RPM packages for this release. Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes: https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/release_notes/ Security Fix(es): * acl: Symlink traversal privilege escalation via libacl functions (CVE-2026-54369) * openssh: OpenSSH: Use-after-free vulnerability during host key re-exchange on the client side (CVE-2026-60002) 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.19 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.19/html-single/updating_clusters/index#updating-cluster-cli.

Improper Verification of Source of a Communication Channel in the ADS discovery of the Go implementation of Apache PLC4X (PLC4Go) allows an attacker able to send UDP datagrams to the discovering host to redirect subsequent connections to an arbitrary, attacker-chosen address. The discovery result's connection address was derived from the AmsNetId claimed in the response body rather than from the datagram's actual source address. One spoofed discovery response can therefore insert an inventory entry pointing at any host, including hosts outside the local network, and an application that connects to discovered devices will open its ADS session, including any configured route credentials, to that host. Additionally, discovery listeners in both implementations can be disabled by a single malformed datagram: - In PLC4Go ADS discovery, a short version block causes a panic that ends the listener for the rest of the discovery call, so legitimate devices answering afterwards are not reported. - In PLC4J, the ADS and EtherNet/IP discoverers stop on an unhandled exception from a malformed response. - The PLC4J Modbus discoverer can be made to spin indefinitely, consuming a CPU core, by a scanned host that sends a partial response. Exploitation requires the application to invoke the discovery API, which is opt-in, and for the connection redirect, to act on the discovered items. This issue affects Apache PLC4X: PLC4Go from 0.11.0 before 1.0.0; PLC4J ADS and Modbus drivers from 0.10.0 before 1.0.0; PLC4J EtherNet/IP driver from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases. Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 derives the connection address from the datagram's source address and logs a warning when the claimed AmsNetId disagrees with it.

Integer Overflow, Improper Validation of Array Index, Uncontrolled Recursion and Memory Allocation with Excessive Size Value in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious device, or an attacker able to inject network traffic, to crash or exhaust the memory of the client application, causing a denial of service. The individual defects are: - Generated parsers pre-allocate arrays with the element count claimed on the wire (0.13.0 through 0.13.1). - Transport read helpers allocate buffers of the size claimed on the wire without an upper bound. - ADS and KNXnet/IP response handling indexes into received data without checking its length, causing a panic. - ADS and EIP frame-length handling accepts, or arithmetically wraps to, a length of zero, breaking message framing. - Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Java implementation is covered by CVE-2026-102509 https://cveprocess.apache.org/cve5/CVE-2026-102509 . Additionally, length and position arithmetic in generated serializers was performed in 16-bit integers. If an application forwards attacker-influenced payloads larger than 8 KB, the length field wraps, and the remainder of the payload may be interpreted by the receiving device (for example, an ADS PLC) as additional, independent protocol messages. This issue affects Apache PLC4X: from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases. Users are recommended to upgrade to version 1.0.0, which fixes the issue.

`download_wheel()` runs `pip download` and hands the result straight to the seeder, with nothing checking the bytes it gets back. The embedded pip and setuptools wheels carry a `BUNDLE_SHA256` that virtualenv checks on every load, but a wheel fetched over the network for the periodic-update feature or the `--download` flag had no equivalent verification. A compromised index, a stale mirror, or a MITM'd download (when TLS is intercepted, e.g. via a misconfigured or malicious CA) could substitute a different wheel under the same distribution/version/filename, and virtualenv would cache and seed it into every environment created afterward with no warning. Fixed by computing the downloaded wheel's sha256 and comparing it against the digest PyPI's public JSON API reports for that exact release, independent of which index actually served the file. The check is skipped, not treated as failure, when a custom index (`PIP_INDEX_URL`, `PIP_EXTRA_INDEX_URL`, `PIP_INDEX`) is configured, since a private index can legitimately serve a different, intentionally rebuilt wheel. Fix: https://github.com/pypa/virtualenv/pull/3251

### Impact The generated `activate` (bash/zsh) and `activate.fish` scripts interpolate a `shlex.quote`-ed value into a position that quotes it a second time. The extra quotes terminate the quoted run early and leave part of the value parsed as shell code, so a path containing shell metacharacters runs commands when a user sources the activation script. `activate` is affected through the virtual environment's own path, on the branch that reports a relocated environment: ```sh echo "Virtual environment directory __VIRTUAL_ENV__ does not exist!" >&2 ``` For a destination named `x'$(id)'y`, `shlex.quote` emits `'x'"'"'$(id)'"'"'y'`. The inner `"` closes the enclosing double quote and `$(id)` is left unquoted. Backtick and `;` payloads reach the same result. This branch runs whenever the recorded path is absent, which is the normal case for a virtual environment copied or distributed to another machine. `activate.fish` is affected through the interpreter's Tcl/Tk library paths: ```fish set -gx TCL_LIBRARY '__TCL_LIBRARY__' ``` `shlex.quote` already returns `'/tcl/(cmd)/lib'`, so the rendered line is `''/tcl/(cmd)/lib''`. fish concatenates the adjacent quoted runs and expands the `(cmd)` left between them. The same doubling also splits a path containing a space into two list elements, corrupting `TCL_LIBRARY` and `TK_LIBRARY`. This is the same defect class as GHSA-x78j-v8h9-3j2q, which covered `activate.bat`. ### Patches Fixed in 21.7.13 by moving the placeholders outside the surrounding quotes, so each value keeps only the quoting `shlex.quote` applied. Fix: https://github.com/pypa/virtualenv/pull/3252 ### Workarounds Avoid creating or distributing virtual environments whose path contains `'`, `` ` ``, `$`, `;`, `(` or `)`, and inspect the generated activation script before sourcing one you did not create.

Joomla Extension - balbooa.com - Unauthorized Deletion of Attachments in Balbooa Forms < 2.4.3.4 - The public removeTmpAttachment action accepts an integer attachment ID and deletes the matching database row and file. The controller verifies a Joomla session token, but the model does not bind that ID to the session that uploaded the file, the current user, the form, the upload field, or the temporary state. Any guest can obtain a token for their own session, so the token prevents CSRF but does not authorize the target object.

### Impact PHPCSUtils versions 1.0.0-alpha1 through 1.2.2 contain an arbitrary code execution vulnerability in `PHPCSUtils\AbstractSniffs\AbstractArrayDeclarationSniff::getActualArrayKey()`. The vulnerable method is reached by any sniff that extends `AbstractArrayDeclarationSniff` and calls `getActualArrayKey()`. Running PHPCS over untrusted PHP code through such a sniff, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host. The vulnerability happens when the method determines the value of an array key using `eval()`. A maliciously crafted array key such as `'system'('id')` would be executed when the code was scanned. ### Known attack vectors Known code paths that reach the vulnerable method include the following PHPCSExtra sniffs: - `Universal.Arrays.DuplicateArrayKey` - `Universal.Arrays.MixedArrayKeyTypes` Other packages that call `AbstractArrayDeclarationSniff::getActualArrayKey()` may also be vulnerable. ### Patches This issue has been fixed in PHPCSUtils 1.2.3. We recommend all users upgrade to 1.2.3 or later. ### Workaround Users who cannot upgrade immediately can disable the sniffs that reach the vulnerable method by adding `<exclude>` tags to their custom ruleset (replace the placeholder standard and sniff names with the ones used in your setup): ```xml <rule ref="Standard"> <exclude name="Standard.Category.SniffName"/> </rule> ``` For example, to disable the two PHPCSExtra sniffs listed under "Known attack vectors": ```xml <rule ref="Universal"> <exclude name="Universal.Arrays.DuplicateArrayKey"/> <exclude name="Universal.Arrays.MixedArrayKeyTypes"/> </rule> ``` To verify that the sniffs have been disabled, run PHPCS with the `-e` flag, which lists all the sniffs a standard will run. The excluded sniffs should no longer appear in the output: ``` phpcs -e --standard=/path/to/ruleset.xml ``` ### Credits Many thanks to [@rodrigoprimo](https://github.com/rodrigoprimo) for responsibly disclosing this vulnerability. ### How can I report a security bug? Please report security vulnerabilities privately via [the "Security and quality" tab on the PHPCSUtils repository](https://github.com/PHPCSStandards/PHPCSUtils/security).

### Summary When `enable_jsonp=True`, oauthlib's `RevocationEndpoint` reflects the user-supplied `callback` parameter directly into JavaScript response bodies on both success and error paths without validating that it is a legal JSONP callback name. This allows arbitrary JavaScript response generation instead of a restricted function call, making the documented JSONP revocation feature unsafe for browser-based JSONP consumption when attackers can influence `callback`. ### Details The issue is in `oauthlib/oauth2/rfc6749/endpoints/revocation.py`. When `enable_jsonp=True` is passed to the `RevocationEndpoint` constructor, two code paths wrap the response body using the user-supplied `request.callback` parameter: ```python # Error response path (line 72-73): if self.enable_jsonp and request.callback: response_body = '{}({});'.format(request.callback, response_body) # Success response path (line 81-82): if self.enable_jsonp and request.callback: response_body = request.callback + '();' ``` The `request.callback` value comes from HTTP request parameters, either the query string or POST body, via the `Request` class in `oauthlib/common.py` (lines 394-395), which merges query and body parameters into `_params`. Any value the client sends as `callback` is used verbatim. There is no validation of any kind on the callback parameter: - No check that it is a valid JavaScript identifier - No whitelist of allowed characters - No escaping or sanitization A safe JSONP implementation must validate that the callback is a legal JavaScript function name (e.g., matching `^[a-zA-Z_$][a-zA-Z0-9_$.]*$`). Without this, the attacker controls the JavaScript code returned in the response body. This is the standard mitigation used by jQuery, Express.js, Google APIs, and other major JSONP implementations. **How the injection works:** An attacker sends a revocation request with a crafted callback value: ``` POST /revoke HTTP/1.1 Content-Type: application/x-www-form-urlencoded token=anything&callback=alert(document.cookie)// ``` The server responds with: ``` alert(document.cookie)//({"error": "invalid_client"}); ``` This is syntactically valid JavaScript. `alert(document.cookie)` executes as a statement, and `//` comments out the rest of the line. The attacker has full control over the code that appears before the `//`. **Execution context and attack surface:** JSONP works by having a browser load a remote script via `<script src="...">`. The loaded script executes in the origin of the **including page**, not the remote server. This means a `<script src="https://auth.example.com/revoke?token=x&callback=payload">` tag on `evil.com` would execute the payload in `evil.com`'s context, not the auth server's context. The impact comes from client-side integrations that consume this endpoint as trusted JSONP. If a legitimate OAuth client includes `<script src>` pointed at the revocation endpoint and an attacker can influence the callback value (e.g., via query parameter injection, a reflected value, or a man-in-the-middle downgrade), the attacker controls what code runs in the client application's origin. The authorization server becomes a source of attacker-controlled JavaScript that client applications trust and execute. Note: the `enable_jsonp` parameter defaults to `False`, so only deployments that explicitly opt in are affected. However, this is a supported, documented library feature, not a debug flag. The client-side library includes `prepare_token_revocation_request()` with an explicit `callback` parameter (`oauthlib/oauth2/rfc6749/parameters.py`, line 174), and the documentation shows JSONP revocation as a use case (`oauthlib/oauth2/rfc6749/clients/base.py`, lines 351-358). The existing test suite tests JSONP callback reflection with a benign value (`test_revocation_endpoint.py`, lines 91-101) but does not test for injection. Deployments that enable JSONP typically do so to support older browsers or cross-origin revocation from JavaScript clients, these are exactly the environments most sensitive to script injection. ### PoC **Requirements:** Python 3.x with oauthlib installed (`pip install oauthlib`). ```python from oauthlib.oauth2.rfc6749.endpoints.revocation import RevocationEndpoint from oauthlib.oauth2.rfc6749.request_validator import RequestValidator class FailValidator(RequestValidator): """Auth fails -> triggers error response path (lines 72-73).""" def client_authentication_required(self, request, *a, **kw): return True def authenticate_client(self, request, *a, **kw): return False def authenticate_client_id(self, client_id, request, *a, **kw): return False class PassValidator(RequestValidator): """Auth passes -> triggers success response path (lines 81-82).""" def client_authentication_required(self, request, *a, **kw): return False def authenticate_client_id(self, client_id, request, *a, **kw): return True def revoke_token(self, token, token_type_hint, request,

Joomla Extension - balbooa.com - Unauthenticated path traversal exfiltrates local files through auto-reply attachments in Balbooa Forms < 2.4.3.4 - Balbooa Forms accepts upload-field state as Guest-controlled JSON during public form submission. For every object whose `id` merely looks numeric, the component trusts the supplied `filename`, concatenates it below the configured upload directory, and adds the result to an array of local attachment paths. It does not load the referenced attachment row, verify ownership/session/form/field, require that the ID exists, canonicalize the path, or enforce containment. If the form's normal “auto reply” and “attach uploaded files” options are enabled, the component sends those local paths as email attachments to the address submitted in an email field. A Guest can therefore submit a nonexistent numeric ID plus a traversal filename such as `../../../../configuration.php` and receive any file readable by the Joomla process.