orderly-plugin-liquidity-heatmap poses as a liquidity heatmap plugin for the Orderly Network orderbook widget, but its only export is an empty stub and a postinstall hook runs `node ./scripts/setup.js` on npm install. When the script detects GitHub Actions (CI and GITHUB_WORKSPACE set), it records the runner's host, user, repository, GITHUB_/ACTIONS_/RUNNER_ variable names, GITHUB_TOKEN presence and length and network egress, and requests an OIDC token from ACTIONS_ID_TOKEN_REQUEST_URL. From 1.0.2 it uses the workflow's GITHUB_TOKEN to commit heatmap-setup-report.json to the default branch of the installing repository, and 1.0.4 also force-pushes a `heatmap-setup-<timestamp>` git tag with the credentials actions/checkout persists in .git/config; 1.0.6 ships the same setup.js as 1.0.4. The npm account dumtban published the six versions between 13:12 and 16:05 UTC on 2026-10-11, each extending the previous one's access to the CI runner.
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (dc82bf27be560cba6faa5304a85b992a07f453c6f9d3f6965f9462666309a3d1)
orderly-plugin-liquidity-heatmap@1.0.0 ships a non-functional main (dist/index.js exports registerLiquidityHeatmapPlugin returning an empty function) with no overlay/interceptor/rendering code — the advertised purpose exists only in the README. The sole real behavior is a postinstall script (scripts/setup.js) gated by `process.env.CI && process.env.GITHUB_WORKSPACE`, so the payload fires only inside GitHub Actions. On that trigger it collects runner identity (hostname, user, repo, workflow, platform), enumerates all GITHUB_*/ACTIONS_*/RUNNER_* environment variable names, records GITHUB_TOKEN presence and length, captures the OIDC request URL, the npm registry, egress probe results, and tool versions, and writes the JSON to `<GITHUB_WORKSPACE>/heatmap-setup-report.json` inside the installer's checked-out repository. In addition, when ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL are set, it uses the installer's OIDC bearer token to call the GitHub ID-token endpoint with `audience=api.github.com` and records the mint result in the same report. The combination of a hollow library stub, CI-environment-only activation, enumeration of secrets-adjacent CI metadata, unauthorized exercise of the workflow's OIDC identity, and placement of the output into the repository workspace where subsequent workflow steps may commit it or upload it as an artifact is a CI-poisoning / supply-chain reconnaissance primitive against the installer's build pipeline.
## Source: ghsa-malware (f25fe3de75e25d7bb2dee4e8cf02e39d79d011bc22a4b52cf0071bf8a73ad2f2)
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.
Improper authorization in the query resolvers generated by @aws-amplify/graphql-index-transformer in AWS Amplify API Category before 3.1.2 might allow an authenticated remote user to read records owned by other users of the same application via crafted queries.
This issue has been addressed in @aws-amplify/graphql-index-transformer 3.1.2 https://www.npmjs.com/package/@aws-amplify/graphql-index-transformer/v/3.1.2 (included in @aws-amplify/data-construct 1.17.4 https://www.npmjs.com/package/@aws-amplify/data-construct/v/1.17.4 and @aws-amplify/graphql-api-construct 1.21.4 https://www.npmjs.com/package/@aws-amplify/graphql-api-construct/v/1.21.4 ). We recommend upgrading to the latest version ensuring any forked or derivative code is patched to incorporate the new fixes and then redeploying their backend.
### Impact
Argo CD runs a shell command in the repo-server when it clones or fetches an SSH Git repository that has a proxy URL. The proxy host and port are copied into an SSH `ProxyCommand`. A host that contains shell metacharacters breaks out of that command and runs in the repo-server.
All versions from v2.11.0 onward are affected, including every currently supported release. v2.10.20 and earlier are not. The behavior was introduced in [9b27aeb1a4](https://github.com/argoproj/argo-cd/commit/9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205) (2024-01-09, [#15864](https://github.com/argoproj/argo-cd/pull/15864)), the change that added SOCKS5 proxy support for SSH Git URLs, and was first released in v2.11.0.
The repository must use SSH. `http`, `https`, and `socks5` proxy URLs all take this path when they are set on an SSH repository. An HTTPS Git repository uses the proxy as an HTTP proxy and does not build this command.
Anyone who can create or update a repository or a repository credential template can set the proxy. That includes a project-scoped repository permission, `argocd repo add --proxy`, and a repository Secret. A credential template applies its proxy to every matching SSH repository that does not have its own credentials. Argo CD runs the command when it tests the repository connection and on later fetches. The process can read other Git, Helm, and OCI credentials stored for the repo-server.
### Patches
A patch for this vulnerability has been released in the following Argo CD versions:
* v3.6.0-rc2
* v3.5.4
* v3.4.10
* v3.3.15
The fix stops passing the proxy host and port through a shell.
Argo CD 2.x and 3.0 through 3.2 are out of support and will not receive a patch. Upgrade to a patched 3.3 or newer release.
### Workarounds
There is no setting that keeps SSH repository proxies and removes the shell command.
* Do not grant repository create or update to untrusted users, including project-scoped repository access. See [RBAC resources](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbac-model-structure) and [project-scoped repositories](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-scoped-repositories-and-clusters).
* Do not set a proxy on an SSH repository or on a credential template that matches SSH repositories. The proxy field is documented in [Configure repositories with proxy](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#configure-repositories-with-proxy). Credential templates are documented in [Credential templates](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#credential-templates). The `--proxy` flag is documented in [`argocd repo add`](https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_repo_add/).
An HTTPS Git repository with an HTTP proxy does not use this command. Review existing repository and credential-template Secrets for unexpected `proxy` values.
### Credits
The Argo CD team would like to thank @kamil-sawicki, @yuvalelarat, @cherez0ff, @McCaulay, @gehan-psbc, @ria-labs-security, @parameter-ai-security, and @zwindler for responsibly disclosing this issue according to our [security reporting guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability).
### References
* Introducing commit: [9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205](https://github.com/argoproj/argo-cd/commit/9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205) ([#15864](https://github.com/argoproj/argo-cd/pull/15864)), first released in v2.11.0
* [Configure repositories with proxy](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#configure-repositories-with-proxy)
### For more information
* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)
* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd
## Summary
In Nginx UI versions 2.2.0 through 2.5.x, the official bundled reverse-proxy topology did not preserve the external client identity used by Gin. The backend treated the local proxy peer as the client because no trusted proxy was configured, while the proxy supplied the actual address in forwarding headers.
## Impact
This has two distinct effects in bundled-proxy deployments:
* **IP allowlist enforcement:** management API requests forwarded by the bundled proxy were identified as loopback and could pass the loopback exception even when the external source was not in the configured allowlist. Protected management operations still required valid credentials; this did not grant unauthenticated administrator access.
* **Login availability:** failed login attempts from different external sources were attributed to one loopback address. An unauthenticated attacker could therefore trigger the shared temporary login-ban threshold and deny password or OTP login to other users behind the proxy until the ban expired. Existing authenticated sessions were not invalidated.
## Remediation
Upgrade to Nginx UI 2.6.0 or later. The fix explicitly trusts only the intended bundled proxy, validates configured trusted proxies, uses the resolved client address consistently, and fails closed when an IP allowlist is enabled but the client address is invalid.
Fix commit: https://github.com/0xJacky/nginx-ui/commit/e30e331303fc21cf077a2bea724bd79e66892eaf
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.14.75. See the following advisory for the container images for this release:
https://access.redhat.com/errata/RHSA-2026:73869
Security Fix(es):
* encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818)
* net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860)
* crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
All OpenShift Container Platform 4.14 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.14/html-single/updating_clusters/index#updating-cluster-cli.
DeskIn versions up to 3.3.4.3 have a privilege escalation vulnerability in the com.deskin.service.installer XPC service. This flaw allows local unprivileged users to execute arbitrary installer packages as root by connecting to the root-owned service without authentication. Exploiting this vulnerability can lead to full root compromise of the affected macOS host.
Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.
This advisory contains the container images for Red Hat OpenShift Container Platform 4.16.72. See the following advisory for the RPM packages for this
release:
https://access.redhat.com/errata/RHBA-2026:73850
Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes:
https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html/release_notes/
Security Fix(es):
* urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion (CVE-2025-66418)
* acl: Symlink traversal privilege escalation via libacl functions (CVE-2026-54369)
* glib: off-by-one error in glib/gkeyfile.c via "g_key_file_get_locale_string_list" (CVE-2026-58014)
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.16 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.16/html-single/updating_clusters/index#updating-cluster-cli.
Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.
This advisory contains the container images for Red Hat OpenShift Container Platform 4.14.75. See the following advisory for the RPM packages for this release:
https://access.redhat.com/errata/RHSA-2026:73864
Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes:
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/release_notes/
Security Fix(es):
* sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data (CVE-2026-11822)
* sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 (CVE-2026-11824)
* acl: Symlink traversal privilege escalation via libacl functions (CVE-2026-54369)
* glib: off-by-one error in glib/gkeyfile.c via "g_key_file_get_locale_string_list" (CVE-2026-58014)
* glib: path traversal in glib/gio/gdbusauthmechanismsha1.c via keyring_lookup_entry and mechanism_client_data_receive (CVE-2026-58015)
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.14 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.14/html-single/updating_clusters/index#updating-cluster-cli.
## Summary
When processing an attacker-controlled Protobuf schema, vulnerable versions of
`datamodel-code-generator` could write a generated weak-import stub outside the
intended `__weak_imports__` temporary directory. Absolute import paths and relative
paths containing `..` could escape this directory.
An attacker could create directories and new files at locations writable by the
process. Relative path traversal could also overwrite existing writable files
because the existence check and the stub write used different base directories.
An existing absolute target was skipped by the existence check.
Written content was limited to a generated Protobuf syntax declaration,
`syntax = "proto2";` or `syntax = "proto3";`, followed by a newline. This issue did
not provide fully attacker-controlled file contents, and direct arbitrary code
execution has not been demonstrated.
These filesystem side effects occurred before `protoc` ran. A subsequent
compilation error did not undo them. A user or CI job must process the
attacker-controlled schema for the issue to be triggered, whether the schema is
supplied as a local file or fetched via `--url`.
The fix has been merged into the parent repository's `main` branch in
[5e94b8f](https://github.com/datamodel-code-generator/datamodel-code-generator/commit/5e94b8f4203198798ec66b8e48217f70af69a0dc). A patched package release is not yet available.
The technical details and PoC below describe the vulnerable implementation before
that fix.
## Affected component
- Repository: `datamodel-code-generator/datamodel-code-generator` (formerly `koxudaxi/datamodel-code-generator`).
- Analyzed at: released **0.80.0** (`pip install datamodel-code-generator==0.80.0`) and `main` @ commit `834731d56c0a90c182a0919f316069cf5ff0659a` (2026-09-13). Both contained the identical vulnerable sink.
- Sink / entry point (`src/datamodel_code_generator/parser/protobuf.py`, line numbers from 0.80.0):
- Source: `WEAK_IMPORT_PATTERN` (`protobuf.py:37`) — attacker-controlled capture group.
- Sink: `_write_missing_weak_imports` (`protobuf.py:391-393`) — `weak_import_dir / import_path` + `mkdir(parents=True)` + `write_text`.
- Timing: called from `_ProtoInputPreparer.__enter__` (`protobuf.py:333`), before `protoc.main(...)` runs inside the `with` body.
- Preconditions: victim runs the tool (CLI or Python API) with `--input-file-type protobuf` on an attacker-controlled `.proto`, supplied as a local file (`--input`) or a remote URL (`--url`). Requires the `grpcio-tools` package (Protobuf support). The attacker does not need privileges on the affected system; filesystem effects are limited to locations writable by the code-generation process.
## Severity
Proposed: **High**. `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` = **7.5**.
- Scored to match the project's own rating of the sibling path-traversal advisories CVE-2026-55389 / CVE-2026-55390, both `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` = 7.5. This finding is the same attack surface (unvalidated path from a processed schema) with the impact moved from confidentiality (read) to **integrity (write)**, hence `C:N/I:H`.
- `AV:N`: the malicious schema can be fetched over the network via `--url`, consistent with how the siblings were scored.
- `I:H`: attacker fully controls the write path and can create arbitrary directory trees and overwrite existing files; only the file *content* is constrained (a fixed `syntax = "proto{2,3}";` line).
- `A:N` chosen conservatively; overwriting build-critical files (lock files, `__init__.py`, entry points) can cause availability loss, which would argue `A:L`.
- Honest alternative: if the reviewer treats "the victim must run the tool on the file" as user interaction (`UI:R`), the score is **6.5 (Moderate)**. The project used `UI:N` for the identical read-path siblings, so `UI:N` is used here for consistency.
## Details
Source pattern — the imported path is captured with no character restriction:
```python
# protobuf.py:37
WEAK_IMPORT_PATTERN = re.compile(r'^\s*import\s+weak\s+"([^"]+)"\s*;', re.MULTILINE)
```
Sink — the captured path is joined and written with no boundary check:
```python
# protobuf.py:383-393 (_write_missing_weak_imports)
for import_path in WEAK_IMPORT_PATTERN.findall(text):
if any((include_path / import_path).exists() for include_path in include_paths):
continue
stub = self.weak_import_dir / import_path # no resolve(), no is_relative_to()
stub.parent.mkdir(parents=True, exist_ok=True) # arbitrary directory tree
stub.write_text(syntax, encoding=self.parser.encoding)
```
Two escape mechanisms, both from `pathlib`'s `/` semantics:
- **Absolute path**: `Path(".../__weak_imports__") / "/etc/x"` == `/etc/x` (an absolute
right operand replaces the base). Creates new files anywhere the process can write.
- **`../` traversal**: `Path(".../__weak_imports__") / "../../x"` climbs out of the
temp directory.
Why the existence guard (line 389) does not protect the write:
A stack overflow vulnerability exists in the Coraza JSON body processor (github.com/corazawaf/coraza/v3) that can cause the entire host process to crash. This occurs due to an unbounded recursion in the gjson.Valid function when processing deeply nested JSON bodies that bypass argument and byte limits. An unauthenticated attacker can trigger this with a crafted JSON request body well within default and recommended size limits, causing a fatal stack overflow that terminates the process unconditionally.
Threat actors are targeting the accommodation industry with email campaigns containing fake guest complaints and inquiries. These emails deliver malicious LNK shortcut files disguised as images, which deploy blockchain-abusing malware families EtherRAT and TONResolver. These malware variants use public blockchain APIs for command and control infrastructure resolution, enabling dynamic infrastructure rotation and evasion of traditional takedown methods. The campaigns evolve from earlier Booking.com spoofing operations and likely use generative AI to create unique email variants, complicating detection.
A path traversal vulnerability (CWE-22) exists in the balbooa.com Gridbox extension for Joomla versions 1.0.0 through 2.20.3.1. The issue occurs in the image preview functionality where the containment logic only checks for prefix matching, allowing access to files in sibling directories outside the intended images root. The vulnerability is limited to certain image file types and is rated medium severity with a CVSS score of 6.3.
A Cross-Site Request Forgery (CSRF) vulnerability exists in the balbooa.com Gridbox extension for Joomla versions 1.0.0 through 2.20.3.1. The vulnerability arises because the addLanguage action does not require a POST request and thus bypasses the Joomla session token validation that is only enforced on POST methods. This allows a GET request to trigger the action without verifying the token, potentially enabling unauthorized actions if the victim has the required permissions.
This report details research on typosquatting domains that visually mimic legitimate domains by using characters from other alphabets, such as Cyrillic, to bypass browser safeguards like those in Chromium. The research demonstrates how attackers register lookalike domains that appear identical to trusted sites (e.g., apple.com) but are distinct due to Unicode character substitutions. The report includes historical examples of typosquatting and homoglyph attacks used for phishing, malware distribution, and credential theft. The research highlights the challenges browsers face in detecting these deceptive domains and the risks posed by such attacks.