LightGBM Has an Attacker-Controlled Out-of-Bounds Write in Model Files

• The Mess: LightGBM trusts structural values inside text-format machine-learning models and uses attacker-controlled node indexes without validating their bounds. A malicious model can turn that mistake into an out-of-bounds memory write during SHAP prediction.
• The Damage: Loading an untrusted model can corrupt process memory and potentially become a stepping stone toward code execution.
• The Fix: Do not load untrusted LightGBM text models on affected versions and track the upstream fix before deploying a patched release.

This is a model-file attack

CVE-2026-92786 affects LightGBM through 4.7.0 and is classified as CWE-787, Out-of-Bounds Write.

The current CVE record assigns CVSS 7.8 High under CVSS 3.1 and 8.5 High under CVSS 4.0. The attack vector is local because the attacker must get a malicious model into the victim’s LightGBM workflow and have it processed.

That distinction matters.

This is not an Internet-facing LightGBM daemon suddenly accepting arbitrary network packets.

The dangerous input is the model itself.

A model can be downloaded from a repository, received from another team, pulled from object storage, attached to an ML pipeline, or otherwise treated as a trusted artifact.

If that model is malicious, the parser becomes the attack surface.

LightGBM validates the size, not the meaning

The vulnerable parser reads arrays describing the decision tree:

• left_child
• right_child
• split_feature

The parser checks that the arrays contain the expected number of entries.

It does not adequately verify that the values inside those arrays actually point to valid nodes or features.

That is the fundamental bug.

The upstream report shows that arbitrary child values can survive parsing and later become array indexes.

A malicious model can therefore contain something equivalent to:

left_child = -1000000000

That value is not immediately rejected.

Later, during tree processing, LightGBM treats negative child values as leaf references and applies a bitwise inversion:

~node

For -1000000000, the result is:

999999999

That number becomes an array index.

And now the program is no longer operating on the model’s legitimate memory structures.

SHAP turns it into a write primitive

The nastiest path appears when LightGBM calculates feature contributions — the functionality commonly exposed through SHAP-style prediction using predict_contrib=True.

The vulnerable code eventually reaches RecomputeLeafDepths().

The problematic operation is effectively:

leaf_depth_[~node] = depth

There is no sufficient bounds check before the write.

The attacker therefore controls the index through the malicious model’s child value.

The upstream researcher demonstrated a value producing an index of 999,999,999, resulting in a write roughly four gigabytes beyond a buffer sized according to the legitimate number of leaves.

This is substantially worse than a predictable crash.

The researcher describes it as a constrained write-what-where primitive: the attacker controls the destination offset and can influence the small value written there.

The normal prediction path has another bug

SHAP is not the only affected execution path.

The split_feature field can also contain an invalid value.

During ordinary prediction, LightGBM uses that value as an index into the caller’s feature buffer.

A sufficiently large value therefore produces an out-of-bounds read.

The upstream report demonstrated values such as:

split_feature = 2000000000

causing a memory fault during normal prediction.

So there are two distinct memory-safety problems:

SHAP / predict_contrib=True

→ attacker-controlled out-of-bounds write

ordinary predict

→ out-of-bounds read and likely crash

Both originate from the same architectural mistake: trusting structural indexes parsed from an untrusted model.

This is not just a theoretical parser problem

Machine-learning models are frequently treated as data rather than executable code.

That makes vulnerabilities in model parsers particularly interesting.

A development team may review Python dependencies, scan containers and sign application binaries while treating a .txt or model artifact as harmless data.

But LightGBM has to interpret that data as a complex executable structure.

The model describes nodes, children, features and other values that directly influence memory accesses.

Once those values are attacker-controlled, the model becomes an input language.

And the parser becomes security-sensitive code.

The researcher demonstrated memory corruption

The upstream report did not merely speculate about an invalid index.

The researcher reproduced the out-of-bounds write against LightGBM 4.6.0 under a debugger.

The faulting instruction was a memory store, and the calculated index came directly from the malicious left_child value.

The report also notes that the ordinary prediction path can be forced into an out-of-bounds read.

The important limitation is that remote code execution was not demonstrated.

The available research establishes memory corruption and a controlled out-of-bounds write, but it does not establish a complete code-execution exploit chain.

Bugstoday should not turn a plausible exploitation path into a claimed RCE.

The attack requires a victim to process the model

The CVSS vector reflects this.

The current record lists:

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

under CVSS 3.1.

The user interaction component is important.

An attacker needs to get the malicious model into the victim’s workflow and have LightGBM load and use it.

That could happen through:

• downloaded models
• shared model repositories
• CI/CD artifacts
• internal ML platforms
• object-storage buckets
• third-party models
• collaborative ML projects
• model exchange between teams
• automated inference pipelines

The exact exposure depends on how the organization obtains and validates models.

The fix is conceptually simple

The upstream fix adds structural validation before the model is accepted.

The proposed patch introduces Tree::ValidateStructure(num_features) and validates every tree loaded from a text model.

Child references must point to legitimate leaves or internal nodes.

split_feature must remain inside the model’s feature range.

Malformed models are rejected during loading rather than being allowed to reach the prediction code.

The patch also fixes exception handling so malformed models return a catchable error instead of potentially terminating the process during parsing.

The tests specifically cover:

• invalid left-child indexes
• invalid right-child indexes
• invalid split-feature indexes
• invalid root references
• models using tree_sizes
• CLI loading
• C API loading

The upstream PR reports the complete test suite passing after the changes.

But there is no released fix yet

This is the uncomfortable part for defenders.

The upstream pull request implementing the validation is still open.

The latest official LightGBM release currently shown by the project is 4.7.0, while the CVE affects versions through 4.7.0.

So there is no official stable version we can honestly tell administrators to install as the CVE fix at the time of writing.

That changes the immediate mitigation strategy.

What ML teams should do now

Until a patched release is available:

Do not load untrusted LightGBM text models.

Treat externally supplied models as hostile input.

For production pipelines:

• verify model provenance
• use trusted repositories
• cryptographically sign model artifacts where possible
• validate model files before loading
• isolate inference workers
• run model processing with minimal privileges
• restrict filesystem access
• restrict outbound network access
• separate model conversion from production inference
• monitor crashes and abnormal process behavior
• avoid giving model-processing workers unnecessary credentials

The strongest practical control is isolation.

If a malicious model reaches an inference worker, that worker should not automatically have access to production databases, cloud credentials, internal APIs and the rest of the environment.

The model supply chain is the real issue

This vulnerability is another reminder that ML security does not stop at the Python package list.

The software supply chain contains more than:

pip install

It also contains:

download model → parse model → build tree → run inference

Every stage processes attacker-controlled or externally sourced material.

A vulnerable parser means a model artifact can cross the security boundary without looking like an executable.

That is exactly why model provenance and sandboxing deserve the same attention as ordinary software dependencies.

Exploitation status

CVE-2026-92786 was published on September 16, 2026.

The current records do not show a CISA KEV listing or confirmed active exploitation. There is public technical research and an upstream fix proposal, but the available evidence does not establish that attackers are currently exploiting the vulnerability in the wild.

That distinction matters.

This is a serious memory-corruption bug, but calling it an active zero-day would go beyond the evidence currently available.

Bugstoday’s take

The interesting part of CVE-2026-92786 isn’t LightGBM itself.

It’s the assumption that a model file is just data.

It isn’t.

LightGBM turns model fields into array indexes and memory operations. Once those fields are attacker-controlled, a malicious model can reach memory corruption without exploiting some exotic kernel primitive or network protocol.

The current public evidence stops at an attacker-controlled out-of-bounds write. RCE has not been demonstrated.

But a four-gigabyte out-of-bounds write in an ML inference process is not something to shrug off.

Until a patched release lands, treat untrusted LightGBM text models as hostile input and isolate anything that has to process them.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Official LightGBM issue #7357 documenting the vulnerability and memory-corruption behavior.
• Official LightGBM PR #7366 containing the proposed structural-validation fix.
• Official LightGBM releases — current stable release information.
• CVE-2026-92786 record with affected versions and CVSS metrics.