davenardella snap7 bis 1.4.3 ReadVar Request src/core/s7_server.cpp PerformFunctionRead Pufferüberlauf

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.0$0-$5k0.00

Zusammenfassunginfo

Es wurde eine Schwachstelle mit der Einstufung kritisch in davenardella snap7 bis 1.4.3 gefunden. Betroffen hiervon ist die Funktion TS7Worker::PerformFunctionRead der Datei src/core/s7_server.cpp der Komponente ReadVar Request Handler. Die Manipulation führt zu Pufferüberlauf. Diese Sicherheitslücke ist unter CVE-2026-15105 bekannt. Der Angriff kann im lokalen Netzwerk angegangen werden. Darüber hinaus steht ein Exploit zur Verfügung.

Detailsinfo

Eine kritische Schwachstelle wurde in davenardella snap7 bis 1.4.3 ausgemacht. Es geht hierbei um die Funktion TS7Worker::PerformFunctionRead der Datei src/core/s7_server.cpp der Komponente ReadVar Request Handler. Durch das Beeinflussen mit einer unbekannten Eingabe kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-787. Dies wirkt sich aus auf Vertraulichkeit, Integrität und Verfügbarkeit.

Die Schwachstelle wurde durch Chuan Wei (CarnegieMe) als 16 in Form eines nicht definierten Issues (GitHub) veröffentlicht. Auf github.com kann das Advisory eingesehen werden. Die Herausgabe geschah hierbei ohne Zusammenarbeit mit dem Hersteller. Die Identifikation der Schwachstelle findet als CVE-2026-15105 statt. Sie ist leicht auszunutzen. Der Angriff kann im lokalen Netzwerk passieren. Das Ausnutzen erfordert keine spezifische Authentisierung. Es sind sowohl technische Details als auch ein öffentlicher Exploit zur Schwachstelle bekannt.

Ein öffentlicher Exploit wurde durch Chuan Wei (CarnegieMe) in Python geschrieben. Der Download des Exploits kann von github.com geschehen. Er wird als proof-of-concept gehandelt. Für den Vulnerability Scanner Nessus wurde ein Plugin mit der ID 326078 (Linux Distros Unpatched Vulnerability : CVE-2026-15105) herausgegeben, womit die Existenz der Schwachstelle geprüft werden kann.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

Unter anderem wird der Fehler auch in den Datenbanken von Tenable (326078) und EUVD (EUVD-2026-42468) dokumentiert. If you want to get best quality of vulnerability data, you may have to visit VulDB.

Produktinfo

Hersteller

Name

Version

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CNA CVSS-B Score: 🔒
CNA CVSS-BT Score: 🔒
CNA Vector: 🔒

CVSSv3info

VulDB Meta Base Score: 6.3
VulDB Meta Temp Score: 6.0

VulDB Base Score: 6.3
VulDB Temp Score: 5.7
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CNA Base Score: 6.3
CNA Vector: 🔒

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Pufferüberlauf
CWE: CWE-787 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Teilweise

Verfügbarkeit: 🔒
Zugang: öffentlich
Status: Proof-of-Concept
Autor: Chuan Wei (CarnegieMe)
Programmiersprache: 🔒
Download: 🔒

EPSS Score: 🔒
EPSS Percentile: 🔒

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Nessus ID: 326078
Nessus Name: Linux Distros Unpatched Vulnerability : CVE-2026-15105

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: keine Massnahme bekannt
Status: 🔍

0-Day Time: 🔒

Timelineinfo

08.07.2026 Advisory veröffentlicht
08.07.2026 +0 Tage VulDB Eintrag erstellt
02.08.2026 +24 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Produkt: github.com

Advisory: 16
Person: Chuan Wei (CarnegieMe)
Status: Nicht definiert

CVE: CVE-2026-15105 (🔒)
GCVE (CVE): GCVE-0-2026-15105
GCVE (VulDB): GCVE-100-376946
EUVD: 🔒
scip Labs: https://www.scip.ch/?labs.20161013

Eintraginfo

Erstellt: 08.07.2026 19:12
Aktualisierung: 02.08.2026 00:23
Anpassungen: 08.07.2026 19:12 (58), 09.07.2026 05:30 (11), 10.07.2026 15:12 (2), 01.08.2026 17:00 (2), 01.08.2026 20:16 (1), 02.08.2026 00:23 (31)
Komplett: 🔍
Einsender: VULL
Editor: VULL
Cache ID: 216::103

Submitinfo

Akzeptiert

  • Submit #851026: Davide Nardella Snap7 master(commit:30f37da3114024a71ba93f7fd855c680b97a406f) Stack-based Buffer Overflow (von VULL)

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Diskussion

 mayur021 (+0)
vor 21 Tagen
On the mechanism behind this entry, verified against 1.4.3 at commit 30f37da.

The entry classifies this as deserialization (CWE-502), and the summary reads "the manipulation with an unknown input leads to a deserialization vulnerability". Nothing on this path deserializes anything. The defect is a failed bounds check caused by an unsigned comparison.

In TS7Worker::ReadArea (src/core/s7_server.cpp) the guard is:

if (PDURemainder-Size<=0)
return RA_SizeOverPDU(ResItemData, EV);
else
PDURemainder-=Size;

Size is declared longword, which is uint32_t (snap_platform.h:119), while PDURemainder is int. In PDURemainder-Size the usual arithmetic conversions promote PDURemainder to unsigned, so the expression can never be <= 0 except on exact equality, and the per-PDU bound never fires.

Instrumenting PerformFunctionRead at FPDULength 480 with 20 items of 201 bytes shows PDURemainder running 279, 78, -123, -324 and on to -3339 while every item is still accepted, and Offset climbing to 3916. The overflow is the response assembly walking past the end of the stack-allocated TS7Answer23 Answer buffer.

So the accurate classification is an out-of-bounds write arising from an integer conversion defect, CWE-787 with CWE-191 as the root, rather than CWE-502. Worth noting that the accepted submit behind this entry is itself titled "Stack-based Buffer Overflow", so the record is already inconsistent with its own source.

Upstream issue 16 attributes the cause to an accounting mismatch between ReadArea and PerformFunctionRead, where the first charges PDURemainder only the raw data length while the second advances Offset by data plus a 4 byte per-item header plus padding. That mismatch is real but accounts for roughly 100 bytes across 20 items, which is not enough to leave the buffer on its own. The signedness defect is what removes the bound entirely.

◂ ZurückÜbersichtWeiter ▸

Might our Artificial Intelligence support you?

Check our Alexa App!