github.com/temporalio/tchannel-go did not reject TChannel call fragments containing checksum metadata but no length-prefixed argument chunks. The fragment reader left its chunk slice empty and then unconditionally selected the first element. A network peer can supply such a malformed call fragment, including as a direct initial call request after completing the standard initialization handshake. On that inbound path, the resulting unrecovered Go slice-bounds panic occurs on a library-created dispatch goroutine and terminates the hosting process. This allows remote denial of service against applications that expose the listener to untrusted peers. The impact is limited to availability; no confidentiality or integrity impact was identified.
github.com/temporalio/tchannel-go did not validate the one-byte checksum-type field in inbound TChannel call frames. A network peer that can reach a listener can complete the standard initialization handshake and send a call request with an unsupported checksum type. The parser uses that value as an index into a four-entry checksum pool, causing an unrecovered Go panic on the connection read goroutine and terminating the hosting process. This allows remote denial of service against applications that expose the listener to untrusted peers. The impact is limited to availability; no confidentiality or integrity impact was identified.
This release of the Red Hat build of OpenTelemetry provides new features, security improvements, and bug fixes.
Breaking changes:
* None
Deprecations:
* None
Technology Preview features:
* None
Enhancements:
* None
Bug fixes:
* Before this update, the Collector used a bare service name (`http://<name>-targetallocator:80`) to contact the Target Allocator, which did not match the standard `NO_PROXY=.svc` entry. As a consequence, on clusters behind a corporate HTTP proxy, the request was routed through the proxy, which returned an HTML authentication page instead of the expected JSON response, breaking the metrics scraping pipeline. With this release, the Target Allocator endpoint uses the FQDN (`http://<name>-targetallocator.<namespace>.svc:80`). As a result, the Collector reaches the Target Allocator directly without routing through the proxy. For more information, see https://issues.redhat.com/browse/TRACING-6784.
Known issues:
* None
A vulnerability has been found in xuxueli xxl-job up to 3.4.2/3.5.0. This vulnerability affects unknown code of the file xxl-job-admin/src/main/java/com/xxl/job/admin/business/controller/JobInfoController.java of the component Task Management Interface. The manipulation of the argument name/author leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
Joomla Extension - OrdaSoft.com - Authenticated, Privileged Remote Code Execution in OrdaSoft Joomla Gallery extension for Joomla < 6.2.7 - The extensions saveWatermark() copied an uploaded file into a web-accessible directory using the client-supplied filename exactly as sent, with no extension check, no content check, and no filename sanitisation of any kind. An authenticated core.manage user could upload a .php file disguised with an image Content-Type header and execute it directly by requesting the resulting path.
Joomla Extension - OrdaSoft.com - Unauthenticated SQL Injection in OrdaSoft Joomla Gallery extension for Joomla < 6.2.7 - The extensions showSearchResult() and showSearchResultAjax() read the textsearch/searchText request parameter with $input->getVar(), which is not a real Joomla filter method and falls through to a filter that strips HTML tags but does not touch quotes or SQL syntax. The value is concatenated directly into a LIKE clause with no escaping. The endpoint requires no login of any kind: mod_osgallery_search is a public, commonly-published search box. Any anonymous site visitor can inject a UNION SELECT and read arbitrary database content.
Joomla Extension - OrdaSoft.com - Authenticated, Privileged SQL Injection in OrdaSoft Joomla Gallery extension for Joomla < 6.2.7 - The extensions saveGallery() passes form data through a hand-rolled parser into Joomla’s Input object, then reads it back with the ARRAY/ STRING filter types, neither of which sanitises SQL content. Values from category_names[], catOrderIds, and image-ordering fields were concatenated directly into SQL with no quoting or integer cast, giving an authenticated core.manage user (a permission scoped to managing one gallery component, not administrator-wide trust) full read/write access to the database, including UNION-based extraction of #__users password hashes.
Joomla Extension - OrdaSoft.com - Authenticated, Privileged Remote Code Execution in OrdaSoft Joomla Gallery extension for Joomla < 6.2.7 - The extensions updateOSGallery(), reached via task=update_osgallery, read a JSON request body and called the value of a method field as a live PHP function, passing the value of a package field as its single argument, with no allow-list or is_callable() check of any kind. Any function name compatible with a single argument was directly reachable, including system, exec, shell_exec, and passthru.
### Summary
GitPython's `Actor.name_email_regex` regular expression (`git/util.py`, line 863)
is vulnerable to catastrophic backtracking (ReDoS — Regular Expression Denial of
Service). When GitPython parses the `author` or `committer` header of a git commit
object that contains a long string with an unterminated `<` (no matching `>`), the
Python regex engine enters quadratic backtracking, causing complete single-threaded
CPU exhaustion proportional to the square of the input length.
A single crafted commit object can block any GitPython API call that reads
`.author` or `.committer` for **over two minutes per invocation**, enabling denial
of service against CI runners, code-hosting backends, repository-scanning
pipelines, or any service that processes commits from third-party or untrusted
repositories.
---
### Details
**Vulnerable file and line:**
`git/util.py`, line 863:
```python
name_email_regex = re.compile(r"(.*) <(.*?)>")
```
This regex is evaluated inside `Actor._from_string()` (line 909) every time
GitPython resolves a commit's `.author` or `.committer` property.
**Full call chain — from public API to vulnerable sink:**
commit.author # any ordinary GitPython API call
└── git/objects/commit.py:917
Commit._deserialize()
└── git/objects/util.py:341
parse_actor_and_date(author_line)
└── git/util.py:909
Actor._from_string(string)
└── Actor.name_email_regex.search(string) ← VULNERABLE
`author_line` is decoded directly from the raw bytes of the git commit object with
**no length limit, character restriction, or timeout** applied at any point before
reaching the regex engine. The same chain is triggered by:
- `commit.author`
- `commit.committer`
- `repo.iter_commits()`
- `repo.blame()`
- Any web service / CI tool that displays or processes commit metadata
**Why this pattern backtracks catastrophically:**
The pattern `(.*) <(.*?)>` contains an unbounded greedy group `(.*)` followed by
a literal space and `<`. When the input is a long string that contains `<` but no
closing `>`, the regex engine must try every possible split position for the greedy
group — O(n²) candidate positions for a string of length n — each of which then
drives the inner lazy group into further sub-match attempts. This is the
well-documented "catastrophic backtracking" failure mode for this family of
patterns.
**Empirically measured scaling (tested against GitPython 3.1.59, commit 52a6cba):**
| Author field length (bytes) | Time to resolve `.author` |
|-----------------------------|--------------------------|
| 1,000 | 0.0035 s |
| 5,000 | 0.084 s |
| 10,000 | 0.341 s |
| 20,000 | 1.525 s |
| 40,000 | 5.963 s |
| 60,000 | 13.360 s |
| 80,000 | 23.871 s |
| **200,000** | **150.488 s** |
Each doubling of input size roughly quadruples processing time (e.g. 40,000 →
80,000 bytes: 5.96 s → 23.87 s ≈ 4.0×), confirming O(n²) growth. Git itself
imposes **no practical size limit** on author name fields in the object format.
**How the malicious object reaches a victim:**
The PoC creates the commit object as a correctly SHA-1-hashed, zlib-compressed git
loose object written directly into `.git/objects/`. `git cat-file -t <sha>` confirms
it is a valid `commit` type and git's own read-side tools display it without error.
Only git's write-side tooling (`git commit --author`, `git update-index`,
explicit `git fsck`) applies the sanity checks that would reject a malformed author
line. Delivery paths that bypass those checks include:
- A git server with `receive.fsckObjects = false` (common in self-hosted deployments)
- A `.git` directory shipped as a tarball, backup, or zip archive
- A git bundle file
- Any automated mirror or import tool that operates at the object level
---
### PoC
**Environment used for testing:**
- GitPython 3.1.59, installed in editable mode from source (no code modifications)
- Python 3.12.3, git 2.43.0, Ubuntu 24.04
**Script 1 — craft the malicious repository (`craft_malicious_repo.py`):**
```python
#!/usr/bin/env python3
"""
Creates a git repository with one commit whose 'author' field is a large
string containing an unterminated '<'. Bypasses git's write-side sanity
checks by writing the raw object directly into .git/objects/.
Usage: python3 craft_malicious_repo.py <target_dir> <payload_size_bytes>
"""
import hashlib, os, subprocess, sys, zlib
def run(cmd, cwd):
return subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)
def main():
if len(sys.argv) != 3:
print(f"usage: {sys.argv[0]} <target_dir> <payload_size_bytes>")
sys.exit(1)
target_dir, payload_size = sys.argv[1], int(sys.argv[2])
os.makedirs(target_dir, exist_ok=True)
run(["git", "init", "--quiet"], cwd=target_dir)
run(["git", "config", "user.email", "poc@example.com"], cwd=target_dir)
run(["git", "config", "user.name", "PoC"], cwd=target_dir)
with open(os.path.join(target_dir, "README.txt"), "w") as f:
f.write("GitPython ReDoS PoC repository\n")
run(
Acode is a powerful text and code editor for Android. From 1.11.6 until 1.12.7, com.foxdebug.acode.rk.exec.terminal.TerminalService is declared as an exported service in src/plugins/terminal/plugin.xml without a binding permission, and src/plugins/terminal/src/android/TerminalService.java does not verify the caller. Any installed Android application can bind the service and send MSG_EXEC with an attacker-controlled cmd value, which the terminal implementation passes to ProcessBuilder with sh -c inside Acode's UID. This allows a zero-permission local application to execute commands with access to Acode private data, remote credentials, Storage Access Framework grants, and runtime permissions without additional interaction at attack time. This issue is fixed in version 1.12.7.
rustls-webpki (the Rust webpki fork used by rustls) versions >= 0.101.0 and prior to 0.103.12 and 0.104.0-alpha.6 incorrectly accepted permitted-subtree DNS name constraints for certificates asserting a wildcard name. For example, a name constraint of accept.example.com was treated as satisfied by a certificate for *.example.com, which could feasibly assert reject.example.com — a name outside the permitted subtree. Because name constraints are restrictions applied to otherwise properly issued certificates, the issue is only reachable after signature verification succeeds and requires a misissued wildcard certificate to exploit.
ArcadeDB (Maven artifact com.arcadedb:arcadedb-engine) through 26.8.1 contains an incomplete deny-list in the polyglot script sandbox: com.arcadedb.query.polyglot.HostClassLookupFilter.DENIED lists java.util.ResourceBundle as a bare class name, which is matched by exact equality and therefore does not cover its subclasses, while ScriptTriggerExecutor.ALLOWED_PACKAGES permits java.util.*. A user with the UPDATE_SCHEMA privilege (sufficient to create or alter a JavaScript trigger; no server-admin rights required) can reference java.util.PropertyResourceBundle or java.util.ListResourceBundle and invoke the inherited static ResourceBundle.getBundle(String) to read .properties resources from the application classpath, which the sandbox (IOAccess.NONE, with java.io.**, java.nio.** and java.net.** denied) is intended to make unreachable. This can disclose packaged application configuration such as database credentials and API keys; the advisory states the issue does not provide arbitrary host filesystem read or remote code execution. Fixed in 26.9.1.
ArcadeDB before 26.9.1 (com.arcadedb:arcadedb-engine <= 26.8.1) fails to bind the authenticated principal onto the DatabaseAsyncTransaction async worker threads used by the parallel edge-connect phase of POST /api/v1/batch/{database}. Because those workers have no current user, LocalDatabase.checkPermissionsOnFile returns early and allows the write, bypassing per-type CREATE_RECORD/UPDATE_RECORD ACL enforcement. In deployments that rely on per-type or per-group ACLs, an authenticated low-privilege user holding CREATE_RECORD on an edge type E but with CREATE_RECORD/UPDATE_RECORD revoked on a vertex type V can submit a graph edge-load batch request (with parallelFlush at its default value of true) and durably append edges to protected vertices of type V by writing records into V's <V>_out_edges/<V>_in_edges buckets, resulting in unauthorized modification of graph adjacency. Setting parallelFlush=false causes the request to be correctly rejected. This is an incomplete fix of GHSA-c23x-pqcj-7hfm, which bound the principal only on the HTTP handler thread.
ArcadeDB (Maven artifact com.arcadedb:arcadedb-engine) through 26.8.1 enforces its per-type/per-record access-control rules only in LocalBucket, keyed on file id. Query-execution paths that reach record data through LSM index files or the TimeSeries engine never invoke that permission check, so an authenticated user who is denied readRecord/deleteRecord on a type can still, with a single ordinary SQL statement, read the type's indexed key values and record IDs (e.g. SELECT key, rid FROM INDEX:Type[field]), read MAX/MIN values via the index shortcut, read and count TimeSeries samples, learn the type's record count, and delete index entries (DELETE FROM INDEX:Type[field]), which desynchronizes the index from the data and can defeat unique constraints. Index and type names needed for exploitation are discoverable because SELECT FROM schema:indexes is unfiltered. The issue affects both embedded and server deployments and all transports (HTTP, Bolt, Postgres, Gremlin) once a principal is bound. Fixed in 26.9.1.
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (826e81131e7b2a296324d469c10f1e44d5b33683703c8a2e0f101a8674c1cfcf)
The package impersonates the Tink open-banking SDK (name @tink/tink-link-core, description 'Enterprise-grade client core for open banking', homepage github.com/tink-link/core) but its actual behavior is host reconnaissance and DNS exfiltration. The package.json install script runs `node index.js`, and both the install entry and main entry load lib/core.js, which reads os.userInfo().username, os.hostname(), and process.cwd(), joins them with a prefix and a hardcoded domain as DNS labels, and issues a dns.resolve4() lookup. The destination hostname and module/API names are reconstructed at runtime from hex byte arrays via Buffer.from(...).toString('utf8') in lib/b02e30.js and lib/6ad264.js — the decoded domain is oob.algamil7x.xyz and the label prefix is tinkcore. Module names 'os','dns','process' and API names 'userInfo','hostname','cwd','resolve4' are loaded via module.constructor._load with hex-decoded strings to hide them from static review. DNS-based egress bypasses HTTP proxy and firewall controls. The beacon fires automatically on `npm install` (via the install lifecycle script) and again on `require()` of the package, giving the attacker installer username, hostname, and current working directory for every affected environment.
A significant supply chain attack compromised Brevo's infrastructure on September 14, 2026, affecting over 100,000 customer websites. Attackers injected malicious code into Brevo's JavaScript assets and widgets, delivering two distinct payloads: a WordPress plugin backdoor automatically installed when site administrators visited their own sites while logged in, and ClickFix overlays targeting regular visitors. The attack vector involved modification of Brevo's CDN-hosted files and creation of malicious subdomains under sendibt1.com. Evidence suggests attackers gained access to Brevo's Cloudflare account, allowing them to modify DNS records and rewrite content dynamically. The malicious activity lasted approximately four hours, from 16:05 to 20:12 UTC. Brevo's prominent clients include eBay, Louis Vuitton, Michelin, and Amnesty International, amplifying the attack's potential impact significantly.
The 3.30.1 release fixes the regression CRW-13015 Get Started / sample cards on the dashboard are empty after upgrade to 3.30. This release provides additional CVE fixes and container dependency updates to Dev Spaces 3.30.
Red Hat OpenShift Dev Spaces provides a cloud developer workspace server and a browser-based IDE built for teams and organizations. Dev Spaces runs in OpenShift and is well-suited for container-based development.
The 3.30 release is based on Eclipse Che 7.121 and uses the DevWorkspace engine to provide support for workspaces based on devfile v2.1 and v2.2.
Users still using the v1 standard should migrate as soon as possible.
https://devfile.io/docs/2.2.0/migrating-to-devfile-v2
Dev Spaces supports OpenShift EUS releases v4.16 and higher. Users are expected to update to supported OpenShift releases in order to continue to get Dev Spaces updates.
https://access.redhat.com/support/policy/updates/openshift#crw
Verizon Cloud for Android (com.vcast.mediamanager) before 26.7.10 contains a path traversal vulnerability that allows co-resident malicious applications to write attacker-controlled bytes outside the intended staging directory by supplying a crafted _display_name value containing path-traversal sequences through exported activities OneTouchUploadActivity and PrintShopCloudActivity. Attackers can exploit the unsanitized filename concatenation in the file-staging sink via ACTION_SEND or ACTION_SEND_MULTIPLE intents to achieve arbitrary file write and inject attacker-controlled content into the authenticated user's Verizon Cloud account without user interaction.
In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com
Scoold is a Q&A and a knowledge sharing platform for teams. Prior to 1.69.0, authenticated users who are not members of a private space can create content in questions belonging to that space because src/main/java/com/erudika/scoold/controllers/QuestionController.java in QuestionController.reply() and src/main/java/com/erudika/scoold/controllers/CommentController.java in CommentController.createAjax() do not apply the canAccessSpace authorization check used by the question read path. With scoold.is_default_space_public set to false and private spaces in use, a user with a valid session and a known or enumerable question identifier can send requests to POST /question/{id} and POST /comment, causing replies and comments to be stored in a thread the user cannot read. This permits unauthorized modification of private discussions and can trigger notifications that reveal the existence or metadata of private activity. This issue is fixed in version 1.69.0.