Search: com.ar

`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.

CVE-2026-102425 is a critical remote code execution vulnerability in the Balbooa Forms extension for Joomla versions 1.0.0 through 2.4.3.3. The vulnerability arises from improper control of code generation (CWE-94) due to the way administrator-defined PHP code executes after public form submissions. Specifically, the extension replaces form-field shortcodes with user-submitted values inside a double-quoted PHP string before calling eval(), enabling attackers to inject and execute arbitrary PHP code. Exploitation requires the use of the optional PHP-after-submission feature with an attacker-controlled shortcode. The vulnerability has a CVSS 4.0 score of 9.5, indicating critical severity. No official patch or vendor advisory is provided in the data, and no known exploits in the wild have been reported.

CVE-2026-101126 is a medium severity vulnerability in the Balbooa Forms extension for Joomla versions 1.0.0 through 2.4.3.3. The flaw involves improper limitation of pathname to a restricted directory, allowing potential path traversal and metadata tampering. The vulnerability arises because the extension processes JSON arrays per upload field, trusting client-supplied filenames and display names without sufficient validation. This can lead to cross-session claiming and unauthorized file metadata manipulation.

Joomla Extension - balbooa.com - Unauthenticated upload filename stored XSS in Balbooa Forms < 2.4.3.4 - The public form upload endpoint validates the uploaded file's extension and detected MIME type, but stores the attacker-supplied original multipart filename verbatim in `#__baforms_submissions_attachments.name`. A later anonymous form submission associates that temporary attachment with the newly created submission. When an administrator opens the submission, the component's JavaScript retrieves the stored attachment record and concatenates `file.name` directly into an HTML string. The complete string is assigned to `innerHTML`.

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.21.35. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHSA-2026:71443 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.21/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.21 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.21/html-single/updating_clusters/index#updating-cluster-cli.

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.16. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:71454 Security Fix(es): * encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818) * net/http: golang: Go net/http: Unencrypted HTTP/2 connections vulnerable to Denial of Service (CVE-2026-56853) * html/template: golang: Go html/template: Cross-Site Scripting via pathological input (CVE-2026-56858) * encoding/xml: golang: Go: Denial of Service via XML decoding recursion depth issue (CVE-2026-56859) * net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860) * crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862) 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.

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.21.35. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:71453 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) * encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818) * mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * html/template: golang: Go html/template: Cross-Site Scripting via pathological input (CVE-2026-56858) * encoding/xml: golang: Go: Denial of Service via XML decoding recursion depth issue (CVE-2026-56859) * net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860) * crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862) 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.21 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.21/html-single/updating_clusters/index#updating-cluster-cli.

Apache Airflow's Snowflake provider did not validate the connection's `account` and `region` fields before interpolating them into request URLs. The SQL API endpoint is built as `https://{account}.snowflakecomputing.com/api/v2/statements`, so an `account` value containing `/`, `?` or `#` demotes the intended domain to a path, query or fragment and leaves the attacker in control of the request host. The provider sends that request with an `Authorization: Bearer` header carrying a JWT minted from the connection's private key, or the configured OAuth or programmatic access token. A user who can edit the Snowflake connection but cannot read its secrets — Airflow gives connection-configuration users write-only access to stored credentials, and a `private_key_file` lives on the worker rather than in the connection — can therefore cause a valid token for the account to be delivered to a host of their choosing and replay it against the genuine Snowflake endpoint. No Dag-authoring ability is required: the attacker edits the connection and waits for an existing Dag to use it. The same unvalidated value was also used to build the OAuth token-request URL and the Cortex Agent base URL. Affects deployments where Snowflake connections are editable by users who are not trusted with the connection's credentials. Users are advised to upgrade to `apache-airflow-providers-snowflake` `6.18.0` or later, which rejects `account` and `region` values containing anything other than letters, digits, `.`, `_` and `-` in every URL the provider builds from them.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (37cd33c0908189c0085fba153be1c42776411968aa5ad652dd7ffdef88b318bc) hardhat-zet@2.0.1 is published under a name that impersonates the Hardhat Ethereum tooling ecosystem, but its README, type definitions and docs/ tree are copied verbatim from the unrelated `pino` logger project (badges and links point at npmjs.com/package/pino and github.com/pinojs/pino). The exported `middleware` in index.js is a no-op Express middleware and matches neither the `hardhat-zet` name nor the pino README. The package's declared main (index.js) top-level-requires./lib/config, which is not a configuration file but a 4,498,609-byte obfuscator.io-style bundle: a 26,113-entry rotated string array behind two runtime decoders (functions v and F), hex-encoded identifiers, and control-flow flattening. All strings and destination URLs are hidden behind the decoders, so this code runs automatically on any `require('hardhat-zet')` and its behavior is not observable without deobfuscation. Publisher metadata (author 'Robert King <hello@jsonspack.com>', bugs URL https://jsonspack.com/issues) ties to neither the Hardhat nor the pino identity. The combination — ecosystem-typosquat name targeting crypto/Hardhat developers, cover-story README lifted from an unrelated popular package, no-op public API, and a multi-megabyte obfuscated payload auto-executed on import — is the shape of a supply-chain stealer aimed at Ethereum developers. ## Source: ghsa-malware (781273d2c802d3781fecccd4434ba418c93ce88edf920b2a1163dbacf7576254) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Red Hat Advanced Cluster Management for Kubernetes provides the capabilities to address common challenges that administrators and site reliability engineers face as they work across a range of public and private cloud environments. Clusters and applications are all visible and managed from a single console—with security policy built in. This advisory contains the container images for Red Hat Advanced Cluster Management for Kubernetes, which add new features and enhancements, bug fixes, and updated container images. See the following Release Notes documentation, which will be updated shortly for this release, for additional details about this release: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.16/html-single/release_notes/index#acm-release-notes

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (a8e49b1abd7c566b17104c5a2823251df2ca253a0fa509d7c19db1c1942ad13d) On require, index.js invokes initializeDaemon() at top level, which uses spawn('node', [lib/check-items.js], { detached: true, stdio: 'ignore' }) followed by child.unref() to launch a persistent background process independent of the parent. The daemon HTTP-GETs a JSON payload from the hardcoded endpoint https://game.spawnrealm.com/api/item-realtime?key=abcdef123456 and passes payload.code to `new Function('require', 'module', payload.code)`, executing server-supplied JavaScript inside the installer's Node process with full `require` access. An RSA signature check is performed against a public key bundled in the package (crypto-config.js), so the author controls both the signing key and the verifier and the check provides no independent integrity guarantee. Anyone controlling game.spawnrealm.com — including via DNS or TLS — can run arbitrary code as the installing user for the lifetime of the host process. The package is advertised as a validator library, and this remote-code-loader behavior is undisclosed and unrelated to the stated purpose.