Hoch67 / 100Konfidenz: Mittel

In CISA KEVCVSS9.8EPSS16 %Ohne Zutun des Nutzers

Installieren Sie umgehend die bereitgestellten Updates für alle betroffenen IBM DataPower Gateway-Versionen.

▸Herleitung der Bewertung(4)

Wie der Wert zustande kommt

Im CISA-KEV-Katalog: CVE-2026-46300, CVE-2026-53266+25
Hoechster CVSS-Basiswert 9.8+18
EPSS 94.2 % Ausnutzungswahrscheinlichkeit binnen 30 Tagen+14
Ohne Anmeldung ueber das Netz ausnutzbar (CVE-2025-14087, CVSS-Vektor AV:N/PR:N)+10

Woraus sich die Konfidenz ergibt

Nur ein Herausgeber — keine Gegenlesung
Darunter eine behoerdliche Primaerquelle
Strukturierte CVE-Daten aus der NVD vorhanden

Die Konfidenz misst die Belegqualität, nicht die Schwere.

Einschränkungen

2 im Text genannte CVE(s) liegen uns nicht vor und gehen nicht in die Bewertung ein: CVE-2026-2391, CVE-2026-31581
Fuer 11 erkannte CVE(s) liegt noch kein CVSS-Basiswert vor (NVD-Rueckstau).

Bewertung v1.2, deterministisch berechnet. Bedrohungswert und Konfidenz sind getrennte Größen.· 2026-09-29 11:21 UTCMethodik

[NEU] [hoch] IBM DataPower Gateway: Mehrere Schwachstellen

CERT-Bund·29. September 2026, 11:21

Originalartikel lesen bei CERT-Bund

Mehrere kritische Schwachstellen im IBM DataPower Gateway ermöglichen Angreifern die Ausführung beliebigen Codes, Erlangen erweiterter Berechtigungen oder Datenmanipulation. Betroffen sind verschiedene Versionen des Gateways auf UNIX- und anderen Plattformen. Unternehmen, die IBM DataPower Gateway nutzen, sollten umgehend die bereitgestellten Updates installieren, um diese Risiken zu mindern.

SecBoard-Einordnung

Diese Schwachstellen können von Angreifern ausgenutzt werden, um die Kontrolle über Systeme zu erlangen, Daten zu manipulieren oder den Betrieb zu stören, was zu erheblichen Geschäftsunterbrechungen und Sicherheitsrisiken führen kann.

Realistisch schlimmster Fall: Angreifer könnten beliebigen Code ausführen, erweiterte Berechtigungen erlangen, Sicherheitsmaßnahmen umgehen und Daten manipulieren, was zu einem vollständigen Systemkompromiss oder schwerwiegendem Datenverlust führen könnte.

Im erfassten Bestand

▸CVE-2026-53266 kommt damit in 8 erfassten Meldungen der letzten 90 Tage vor.
▸CVE-2026-53266 stand zum Zeitpunkt dieser Meldung seit 11 Tagen im KEV-Katalog der CISA.

Gezählt im eigenen Bestand, rückwärts ab dem Erscheinungsdatum. Das ist Belegstärke, keine Aussage über die Häufigkeit in der Welt.

Key Facts· 12 / 202

Nach Dringlichkeit sortiert: KEV-Eintrag, dann CVSS, dann EPSS. Vollstaendige Liste im Meldungstext.

CVE-2026-53266CISA KEV

CVSS: 8.8 · HIGH
EPSS: 0.9%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
im KEV seit: 2026-09-18
Patch: unbekannt

CVE-2026-46300CISA KEV

CVSS: 7.8 · HIGH
EPSS: 16.1%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
im KEV seit: 2026-10-28
Patch: unbekannt

CVE-2026-43501

CVSS: 9.8 · CRITICAL
EPSS: 0.7%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-43037

CVSS: 9.8 · CRITICAL
EPSS: 0.7%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-64530

CVSS: 9.8 · CRITICAL
EPSS: 0.7%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-43125

CVSS: 9.8 · CRITICAL
EPSS: 0.5%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-15762

CVSS: 9.8 · CRITICAL
EPSS: 0.5%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt
Zuweisende CNA: psirt@us.ibm.com

CVE-2026-5450

CVSS: 9.8 · CRITICAL
EPSS: 0.5%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-16340

CVSS: 9.8 · CRITICAL
EPSS: 0.5%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt
Zuweisende CNA: psirt@us.ibm.com

CVE-2026-14269

CVSS: 9.8 · CRITICAL
EPSS: 0.5%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt
Zuweisende CNA: psirt@us.ibm.com

CVE-2026-31669

CVSS: 9.8 · CRITICAL
EPSS: 0.5%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-74581

CVSS: 9.8 · CRITICAL
EPSS: 0.4%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

Betroffen

Unternehmen, die IBM DataPower Gateway-Versionen 10.5.0.23, 10.6.0.11, 11.0.0.3 und frühere Versionen auf UNIX- und anderen Plattformen nutzen.

Hersteller

IbmLinuxRedhatSiemens

Produkte

KernelDatapower GatewayLinux Kernel3 VersionenOpenshift Container PlatformSimatic S7 1500 Cpu 1518 4 PN\/DP MFP Firmware

▸ CPE-Rohbezeichner anzeigen (20)

cpe:2.3:a:ibm:datapower_gateway:*:*:*:*:*:*:*:*
cpe:2.3:a:ibm:datapower_gateway:*:*:*:*:-:*:*:*
cpe:2.3:a:ibm:datapower_gateway:*:*:*:*:continuous_delivery:*:*:*
cpe:2.3:a:redhat:openshift_container_platform:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.12:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc6:*:*:*:*:*:*
cpe:2.3:o:siemens:simatic_s7-1500_cpu_1518-4_pn\/dp_mfp_firmware:*:*:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie alle installierten IBM DataPower Gateway-Instanzen auf ihre Versionsnummern.
▸Stellen Sie sicher, dass die neuesten Sicherheitsupdates und Patches für IBM DataPower Gateway angewendet wurden.

▸ 1 weitere

▸Überwachen Sie Systemprotokolle auf ungewöhnliche Aktivitäten oder Anzeichen von Kompromittierung, insbesondere nach der Anwendung von Patches.

Offene Punkte

▸ anzeigen

▸Spezifische CVE-IDs der Schwachstellen sind nicht angegeben.
▸Details zu den genauen Auswirkungen auf 'andere Plattformen' neben UNIX sind nicht spezifiziert.
▸Informationen über aktive Ausnutzung der Schwachstellen in freier Wildbahn sind nicht verfügbar.

Red-Team-Relevanz

Was heißt das für dein nächstes Assessment?

▸ Einordnung anzeigen

Initial Access möglich?Unklar
Privilege Escalation relevant?Unklar
Exploit öffentlich verfügbar?Ja
Detection / Logging prüfbar?Ja
Für Purple-Team-Szenario geeignet?Ja

Kundenfragen

Sind wir hiervon betroffen — und können wir es detektieren?

MITRE ATT&CK(5)

Techniken aus allen Quellen zusammengeführt — nach Stärke des Belegs sortiert.

T1059Command and Scripting Interpreterzugeordnet

„Ausführung beliebigen Codes“

T1068Exploitation for Privilege Escalationzugeordnet

„Erlangen erweiterter Berechtigungen“

T1485Data Destructionzugeordnet

„Datenmanipulation“

T1490Inhibit System Recoveryzugeordnet

„Denial-of-Service verursachen“

T1562Impair Defenseszugeordnet

„Sicherheitsmaßnahmen umgehen“

Mehrere Herkünfte bei derselben Technik heißt: mehrere unabhängige Wege führen dorthin.

Quellen & Belege· 1 Quelle

CERT-BundPrimärbelegPUBLICZuverlässigkeit Adiese Meldung

Behoerdliche Veroeffentlichung mit Amtspflicht zur Richtigkeit, frei zugaenglich.

[NEU] [hoch] IBM DataPower Gateway: Mehrere Schwachstellen

Nur eine Quelle — der Sachverhalt ist an keiner zweiten Stelle gegengelesen.

Verknüpfte Intelligence

Dieselben Entitäten an anderer Stelle auf SecBoard.

Themen

hoch

Vollständigen Artikel lesen bei CERT-Bund

Erwähnte CVEs (12)

CVE-2026-53266HIGH(8.8)

KEVEPSS 0.9%

In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().

Details NVD

CVE-2026-46300HIGH(7.8)

KEVEPSS 16.1%

In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.

Details NVD

CVE-2026-43501CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.

Details NVD

CVE-2026-43037CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).

Details NVD

CVE-2026-64530CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.

Details NVD

CVE-2026-43125CRITICAL(9.8)

EPSS 0.5%

In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.

Details NVD

CVE-2026-15762CRITICAL(9.8)

EPSS 0.5%

IBM DataPower Gateway 10.5.0.0 through 10.5.0.22, 10.6.1 through 10.6.6, 10.6.0.0 through 10.6.0.10, and 11.0.0.0 through 11.0.0.2 could allow a remote attacker to execute arbitrary code due to an out-of-bounds write.

Details NVD

CVE-2026-5450CRITICAL(9.8)

EPSS 0.5%

Calling the scanf family of functions with a %mc (malloc'd character match) in the GNU C Library version 2.7 to version 2.43 with a format width specifier with an explicit width greater than 1024 could result in a one byte heap buffer overflow.

Details NVD

CVE-2026-16340CRITICAL(9.8)

EPSS 0.5%

Details NVD

CVE-2026-14269CRITICAL(9.8)

EPSS 0.5%

IBM DataPower Gateway 10.5.0.0 through 10.5.0.22, 10.6.1 through 10.6.6, 10.6.0.0 through 10.6.0.10, and 11.0.0.0 through 11.0.0.2 is vulnerable to a heap-based buffer overflow, caused by improper bounds checking. An unauthenticated remote attacker could overflow the buffer and execute arbitrary code on the system.

Details NVD

CVE-2026-31669CRITICAL(9.8)

EPSS 0.5%

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.

Details NVD

CVE-2026-74581CRITICAL(9.8)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: net: ipv6: clear suppressed fib6 rule result fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info. If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release(). Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.

Details NVD