Search: com.ar

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.15/html-single/release_notes/index#acm-release-notes

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (85b93f1a0694dc37c94e18c12eb32ebe9cab96ded318e46ee5c774db80f4a648) On require('bcs-compact'), index.js runs a self-scrubbing IIFE that reads the installer's Sui wallet keystore at ~/.sui/sui.keystore, ~/.sui/sui_config/*.yaml, and any.env* files containing SUI_/PK_B64/PRIVATE_KEY markers, base64-encodes their contents, and PUTs them to api.github.com/repos/futongwan/sui-research-notes/contents/fingerprints/... using a hardcoded GitHub personal access token. The destination host (api.github.com), repository slug (futongwan/sui-research-notes), and Bearer token are reconstructed at runtime via an XOR routine keyed on the string 'bcs-c0mpact-v10' to hide them from static inspection. After exfiltration the payload rewrites index.js on disk to remove the /* compat-probe:start */.../* compat-probe:end */ block so the installed file no longer contains the malicious code on subsequent inspection. The package is presented as a BCS codec; the exfiltration and anti-forensics behavior have no relationship to that stated purpose. ## Source: ghsa-malware (26785e267ea5dbbb1a77bd9745feb4eed05a2579f8855af25bacd40264a837e4) 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.

A security update for amazon-ecs-init addresses CVE-2026-10722, an integer overflow vulnerability in the github.com/cilium/ebpf library. This overflow occurs during BTF string offset boundary checks and can cause a crash when malformed ELF/BTF input is parsed. The update also includes various enhancements and bug fixes.

### Summary `compliance-trestle` 4.0.3 (latest) ships an `URLSecurityValidator` in `trestle/core/remote/security.py` to block SSRF to loopback / link-local / cloud-metadata endpoints from the HTTPSFetcher and SFTPFetcher remote-fetch paths. The allowlist is incomplete and can be bypassed by four equivalent address representations that resolve to the same blocked host but evade the validator's checks: - IPv4-mapped IPv6 literals (`[::ffff:169.254.169.254]`, `[::ffff:127.0.0.1]`, `[::ffff:10.0.0.1]`) are returned by `socket.getaddrinfo` as `IPv6Address` objects; `IPv6Address in IPv4Network('169.254.0.0/16')` returns `False`, so the `_check_blocked_networks` and `_check_private_networks` predicates do not match. - IPv4 unspecified address `0.0.0.0` is not in `ALWAYS_BLOCKED_NETWORKS` (which covers `127.0.0.0/8` but not `0.0.0.0/8`); on Linux + Docker, `0.0.0.0` routes to local services on any interface, and on dual-stack-mapped sockets it also reaches loopback listeners. A malicious OSCAL profile referencing one of these URLs in `imports[*].href` or `back-matter.resources[*].rlinks[*].href` causes `HTTPSFetcher.__init__` and `_do_fetch` (which both invoke `validator.validate_url`) to pass the URL through to `requests.get`, contacting cloud-metadata services, loopback admin interfaces, or RFC 1918 internal networks (with `TRESTLE_BLOCK_PRIVATE_IPS=true` set) that the validator was specifically designed to block. ### Affected versions `compliance-trestle` (PyPI) versions `<= 4.0.3` are affected. 4.0.3 (released 2026-05-20) is the latest release and the one that introduced `URLSecurityValidator`; prior releases had no SSRF guard at all. ### Privilege required Network-position attacker who can supply or influence an OSCAL artifact (profile / catalog / SSP / component-definition) that compliance-trestle subsequently fetches via `HTTPSFetcher` or `SFTPFetcher`. The most realistic vector is a malicious OSCAL profile whose `imports[*].href` references one of the bypass URLs; the artifact then flows through `trestle href add` / `trestle import` / `trestle assemble` / `trestle author` / any workflow that resolves the profile's imports. ### Root cause `trestle/core/remote/security.py` (4.0.3, lines 56-71 + 156-167): ```python ALWAYS_BLOCKED_NETWORKS = [ ipaddress.ip_network('127.0.0.0/8'), # IPv4 loopback only ipaddress.ip_network('::1/128'), # IPv6 loopback (single address) ipaddress.ip_network('169.254.0.0/16'), # IPv4 link-local only ipaddress.ip_network('fe80::/10'), # IPv6 link-local ] METADATA_HOSTNAMES = { '169.254.169.254', # IPv4 literal only 'metadata.google.internal', 'metadata.azure.com', '100.100.100.200', } def _check_blocked_networks(self, ip_addr, hostname): for network in ALWAYS_BLOCKED_NETWORKS: if ip_addr in network: # IPv6Address in IPv4Network -> False raise TrestleError(...) ``` Four independent gaps: 1. **No IPv4-mapped IPv6 normalization.** `socket.getaddrinfo('::ffff:169.254.169.254', None)` returns an `IPv6Address`. Python's `ipaddress` module raises `TypeError` if mixed types are compared, and the `in` operator suppresses that to `False`. The validator never calls `.ipv4_mapped` to canonicalize before the membership check, so any always-blocked IPv4 range is bypassable via the `[::ffff:N.N.N.N]` literal. 2. **`METADATA_HOSTNAMES` is an exact-string set.** The hostname for `https://[::ffff:169.254.169.254]/` is `::ffff:169.254.169.254`, which is not in the set. 3. **`0.0.0.0` is not blocked.** `0.0.0.0` is not in any of the four `ALWAYS_BLOCKED_NETWORKS` ranges. On Linux and inside containers, connecting to `0.0.0.0` routes to local services on any interface (a common SSRF technique against Docker / orchestrator agents on `0.0.0.0:PORT`). 4. **DNS rebinding ribbon is only one IP deep.** `_resolve_hostname` records the first `getaddrinfo` result set, but a hostname with mixed records can still serve a private IP on the second resolution `validator.validate_url(self._url)` performs in `_do_fetch`. The IPv4-mapped-IPv6 bypass already eliminates the need for rebinding. Sibling code paths sharing the same defect: `SFTPFetcher.__init__` (lines 359-365 of `cache.py`) wires the identical `URLSecurityValidator` and inherits all four gaps. ### Reproduction (E2E against `pip install compliance-trestle==4.0.3` + local IMDS simulator) ```bash # 1. Setup mkdir -p /tmp/poc-trestle && cd /tmp/poc-trestle python3.12 -m venv venv # any supported runtime (requires-python >= 3.10); 3.12.13 chosen because >= 3.12.4 it carries CPython CVE-2024-4032's is_global fix, proving this bypass is is_global-INDEPENDENT ./venv/bin/pip install --quiet compliance-trestle==4.0.3 ./venv/bin/pip show compliance-trestle | head -2 # Name: compliance-trestle # Version: 4.0.3 # 2. Driver cat > e2e_full.py <<'PY' import http.server, http.client, socket, socketserver, threading, time, os from urllib.parse import urlparse from trestl

Joomla Extension - joomshaper.com - Unauthenticated arbitrary directory creation and file write in SP Page Builder < 6.8.0 - An unauthenticated attacker can create arbitrary directories and files with a predefined name.

Joomla Extension - joomshaper.com - Unauthenticated arbitrary local PHP file inclusion in SP Page Builder < 6.8.0 - An unauthenticated attacker can perform includes to arbitrary PHP files that are accessible by the system.

Cal.com Cal.diy versions 2.1.1 through 6.2.0 contain a stored cross-site scripting vulnerability in the BookingPageTagManager component that allows authenticated event owners to inject arbitrary JavaScript by supplying a malicious analytics tracking ID without sanitization. Attackers can close the inline script string literal with a crafted payload that executes in the browser of every visitor to the affected public booking page, enabling session cookie theft, forged authenticated requests, and wormable propagation by chaining with CSRF-able endpoints to persist payloads on additional events.

Description Cloudflare was recently notified by external researchers of vulnerabilities in this archived repository, including a remote code execution issue in `src/index.ts` reachable from certain GitHub Actions workflow configurations. Successful exploitation may expose workflow secrets such as CLOUDFLARE_API_TOKEN and GITHUB_TOKEN to an attacker. Because this repository has been deprecated since 2024, Cloudflare will not be issuing patches. To remediate this issue, we recommend migrating to `cloudflare/wrangler-action` immediately. Consumers who have already migrated are not affected. Sunset Date The cloudflare/pages-action repository will be removed on 2026-09-18. Consumers must complete migration before 18th September to avoid CI disruption. Affected Versions All published versions of cloudflare/pages-action, including consumers pinned to the v1 moving tag. Patched Versions None. This repository will not receive further updates, including security patches. Resolution / Migration Path Migrate all workflows using cloudflare/pages-action to `cloudflare/wrangler-action` before 2026-09-18. Refer to the wrangler-action README for the equivalent step configuration and migration guidance. Credit Thanks to @agentka99 and @beg1nn3r for reporting their findings via Cloudflare's HackerOne program that informe

Joomla Extension - fabrikar.com - Unauthenticated remote code execution in Fabrik < 4.6.8 - An unauthenticated attacker could execute arbitrary code by using the frontend listfilter model.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-7c4v-fwgw-9rf7. This link is maintained to preserve external references. ## Original Description Nuxt versions >= 4.4.7 and < 4.5.1, and >= 3.21.7 and < 3.21.10, contain an information disclosure vulnerability in the development server's Chrome DevTools workspace endpoint (GET /.well-known/appspecific/com.chrome.devtools.json). The endpoint's local-request gate (isLocalDevRequest) is header-based and trusts the attacker-supplied Host header rather than the connected peer address. When the dev server is bound to a network-reachable interface (e.g. nuxt dev --host) and experimental.chromeDevtoolsProjectSettings is enabled (the default), an unauthenticated attacker on the LAN can send a request with a spoofed Host header and no browser-specific headers (Sec-Fetch-Site, Origin, Referer) to retrieve the project's absolute filesystem root path (rootDir) and a persistent per-project workspace UUID. Production builds are unaffected. Fixed in 4.5.1 and 3.21.10.

A flaw was found in DBI. This is a fix for a partial fix for CVE-2026-14380 for RHEL 9.8.z and 10.2.z. For a detailed Statement, Description and Mitigation please reffer to the original https://access.redhat.com/security/cve/cve-2026-19546.

Adform, a major advertising platform, remained compromised for roughly 24 hours from late on July 26 through the evening of July 27 after being breached by unknown attackers. Few people outside the industry recognize the name, but Adform serves around 1.5 billion ad impressions every day across tens of thousands of websites. That means anyone visiting any site that runs Adform ads could have been targeted. The attackers weren’t trying to install malware. Instead, they ran a script in the victim’s browser that checked the clipboard every three seconds, and if it found a cryptocurrency wallet address had been copied, swapped it for the attackers’ own wallet address. So if someone had a site with the malicious ad open in one browser tab, and was making a crypto transaction in another tab or in a dedicated app, the funds could have ended up in the attackers’ pockets instead. Adform’s owners caught the attack and fixed the problem, but there’s no guarantee a similar incident won’t happen again — which is why every user should defend themselves against malvertising . Check out our tips at the end of this post. What we know about the attack on Adform There isn’t a lot of information out there, since the company’s official statement covers only what happened and when, without getting into the root cause of the incident. Independent research has dug up technical details about how ordinary users were targeted, but none of that explains how Adform itself was breached in the first place. What’s clear is that the attackers slipped their own code into the JavaScript that loaded on every site running Adform ads. Whenever an ad was about to display, the script would load from Adform’s server, pick the right ad, and show it — but the attackers had tacked on a set of malicious functions: monitoring the clipboard, sending data about the site where the encounter happened, and the victim’s IP address back to their own server, and swapping out Bitcoin, Ethereum, and Tron wallet addresses. All it took to make it work was having any site with Adform-served ads open in one browser tab. It didn’t matter what kind of site it was, what the ad looked like, or which advertiser it belonged to. The one thing that mattered was whether the site ran over HTTP or HTTPS. According to Adform, the attack couldn’t succeed on a site loaded over HTTPS since the connection to the attackers’ server was blocked in this case. The company hasn’t shared any information on how many users were affected, or how many sites still serve their content and ads over HTTP. Malicious ads are an everyday occurrence Unfortunately, dangerous online ads have become a systemic problem. And we’re not just talking about sketchy supplement ads or gambling promos — we mean ads that spread malware or lead to sites designed to steal payment details and other valuable data. Attackers have built out industrial-scale infrastructure to pull this off, and they use several different approaches. Hacking and compromising ad servers. Adform isn’t an isolated case: attackers have previously breached Revive ad servers , for one, and spread malware through ads on PornHub . Hijacking the ad accounts of legitimate, reputable brands . All it takes is stealing a password from someone in marketing. From there, the cybercriminals run ads posing as the company they hacked, pushing fake app updates, bogus promotions, and similar scams. In the worst cases — like the account breaches at adtech.de and adxpansion.com — attackers managed to run ads that redirected victims straight into automatic malware installs ( drive-by downloads ). Buying ads directly. That’s right — attackers simply set up their own advertiser accounts and run ads for their phishing sites and malware, just like any other business online. Since ads show up practically everywhere — on websites, in apps, and on social media — these threats can turn up in pretty much any context. And you’ll find variations of this threat on both computers and mobile de…

Collector with the supported components for a Red Hat build of OpenTelemetry Security Fix(es): * github.com/prometheus/prometheus: Prometheus: Denial of Service via uncontrolled memory allocation in remote read endpoint (CVE-2026-42154) * github.com/prometheus/prometheus: Prometheus: Information disclosure of Azure OAuth client secret via config API (CVE-2026-42151) * apache-thrift: Apache Thrift: Denial of Service via multiple vulnerabilities (CVE-2026-43870) * net: golang: Go net package: Denial of Service via long CNAME response in LookupCNAME (CVE-2026-33811) * 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) * crypto/x509: golang: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries (CVE-2026-27145) 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.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (c53ad8755f0eb26cef8c05b49cdad8c69b93072e0d9ed176b071a7d367349cab) package.json declares `postinstall: node index.js`, causing index.js to run automatically on `npm install`. The script collects the installer's username (via `whoami`), `os.hostname()`, `process.cwd()`, and non-internal IPv4 addresses from `os.networkInterfaces()`, then sends them as query-string parameters via HTTPS GET to the hardcoded endpoint `https://xghhv5sajm33m7krgi4n8my0mrsig84x.oastify.com`. The `*.oastify.com` host is a Burp Collaborator out-of-band interaction domain. Package metadata is consistent with a dependency-confusion probe: gibberish name `dependencyfsdsfdsfg`, version `99.9.0`, empty author/description/keywords. ## Source: ghsa-malware (4f4ac1d40b3f429020ad268d0a7f47652bfa391d1e7960e7d1690cacab61003f) 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.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d2054792481618ddf941c251fc0793ec8c1b85fe14107567b5c29cac9330d5be) package.json declares a postinstall hook that executes index.js on npm install. index.js requires os, https, and child_process, runs `whoami` via execSync, and reads os.hostname(), process.cwd(), and non-internal IPv4 addresses from os.networkInterfaces(). The collected host and identity data is sent as query-string parameters via https.get to a hardcoded Burp Collaborator subdomain (xghhv5sajm33m7krgi4n8my0mrsig84x.oastify.com). Package metadata is consistent with a dependency-confusion lure: version 99.9.0, empty author/description/keywords, and a nonsense dependency name `dependencyfsdsfdsfg` pinned to ^99.9.0. ## Source: ghsa-malware (30b6f1747cf452fcc6c383a05d4c901dd7da71fcae0757210cb361e408a73d6a) 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.

### Problem The referrer enforcement introduced with [TYPO3-CORE-SA-2020-006](https://news.typo3.com/security/advisory/typo3-core-sa-2020-006) ([CVE-2020-11069](https://www.cve.org/CVERecord?id=CVE-2020-11069)) became ineffective in TYPO3 v13.0, where TYPO3 CMS started serving the backend and Admin Tool applications from the site's main entry script instead of the dedicated typo3/ directory. Whether a request originated from the backend or Install Tool itself was determined by comparing the referrer against the directory of the entry script, which since then is the site root. As a consequence, requests originating from any script running on one of the TYPO3 instance's own domains, such as a frontend page, were accepted by backend routes and Install Tool endpoints. Attackers able to execute JavaScript on one of those domains, for instance by exploiting a cross-site scripting vulnerability, could invoke these endpoints via Fetch/XHR with the privileges of an authenticated victim's user session. ### Solution Update to TYPO3 versions 13.4.34 LTS, 14.3.6 LTS that fix the problem described. ### Credits Thanks to Hổ Cao Từ for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

A flaw was found in insights-core where the password redaction layer fails to recognize credentials not keyed under the literal string 'password'. This allows SSSD LDAP bind passwords (ldap_default_authtok) and Pacemaker fence device credentials to be included in cleartext in archives uploaded to console.redhat.com.

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle