-
CVE-2026-9010
•
published on May 20, 2026
The Boost plugin for WordPress is vulnerable to time-based SQL Injection via the 'current_url' and 'user_name' parameters in versions up to, and including, 2.0.3 due to insufficient escaping on the user supplied parameters and lack of sufficient preparation on the existing SQL queries. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
-
CVE-2026-9009
•
published on May 28, 2026
The Crawlomatic Multipage Scraper Post Generator plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 2.7.2 via the filter_content function. This is due to passing the attacker-supplied 'callback_raw' shortcode attribute directly into call_user_func() with no sanitization or allowlist validation, relying solely on an is_callable() check that permits dangerous PHP built-ins such as system, shell_exec, exec, passthru, and assert. This makes it possible for authenticated attackers, with author-level access and above, to execute code on the server. An identical sink exists for the 'callback' attribute, providing a second independent vector through the same shortcode.
-
CVE-2026-9008
•
published on June 6, 2026
The Page-list plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 6.2. This is due to the pagelist_unqprfx_ext_shortcode() function (the [pagelist_ext] / [pagelistext] shortcode) accepting attacker-controlled post_status, post_type, and show_meta_key attributes and passing them directly into get_pages() and get_post_meta() with no capability check verifying that the rendering user is permitted to read the matched objects. When the current post has no child pages, the shortcode re-issues the query with child_of = 0, broadening it to every page on the site matching the supplied status/type. This makes it possible for authenticated attackers, with contributor-level access and above, to disclose the titles, body content/excerpts, and arbitrary post meta of unrelated private and draft pages by inserting the shortcode into a contributor-authored draft and previewing it.
-
CVE-2026-9007
•
published on July 15, 2026
Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in HCL Notes from HCL Software allows reflected
Cross-Site Scripting (XSS).
Successful exploitation allows an attacker to execute arbitrary JavaScript in the context of another user.
This issue affects HCL Notes: Release 12.0.2FP5HF8 on Linux 4.18.0-553.52.1.El8_10.X64_64#1.
-
CVE-2026-9006
•
published on June 22, 2026
IBM WebSphere Application Server 9.0, and 8.5 is vulnerable to server-side request forgery (SSRF) with the Ajax Proxy configured. This may allow an attacker to send unauthorized requests from the system, resulting in a security bypass or information disclosure.
-
CVE-2026-9004
•
published on September 22, 2026
The WP-CRM System – Manage Clients and Projects plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.4.6 via the 'contact_id' parameter. This makes it possible for authenticated attackers, with contributor-level access and above, to extract full names, email addresses, phone numbers, mobile numbers, fax numbers, and physical address information of arbitrary CRM contact records by enumerating the contact_id parameter.
-
CVE-2026-9003
•
published on May 20, 2026
E-LAN Hybrid Recording System developed by TONNET has a SQL Injection vulnerability, allowing unauthenticated remote attackers to inject arbitrary SQL commands to read database contents.
-
CVE-2026-9002
•
published on June 30, 2026
IBM WebSphere Extreme Scale 8.6.1.0 through 8.6.1.6 could allow an adjacent attacker to cause a denial of service due to improper validation in the XDF decoder. The application processes deeply nested Protocol Buffers messages and attacker-controlled length prefixes without sufficient bounds checking, which may allow an attacker on the same network to trigger a StackOverflowError or OutOfMemoryError, resulting in a crash of the WebSphere Application Server JVM.
-
CVE-2026-99999
•
published on October 15, 2026
In the Linux kernel, the following vulnerability has been resolved:
ipv4: validate checksum_start before completing checksum
If a packet with bad checksum metadata gets into the ipv4 stack,
skb_checksum_help can corrupt the network header and cause a bunch of
mischief.
This was discovered and reported by Paulos, and has been reporoduced
by others independently since.
We really shouldn't allow such packets in, but as a defence
in depth measure, let's also check before we complete the checksum.
A more complete validation at input is forthcoming, but needs more work.
-
CVE-2026-99288
•
published on November 10, 2026
In the Linux kernel, the following vulnerability has been resolved:
inet: reject unhashed sockets during established lookups
TCP established ehash lookups are lockless. The socket caches involved
use SLAB_TYPESAFE_BY_RCU, so memory can be reused before an RCU reader
that retained its old address has finished.
After a tuple match, __inet_lookup_established() and
__inet6_lookup_established() acquire a reference and repeat the tuple
check. They do not check whether the new object is hashed. If the
address is reused for a socket with the same tuple, the lookup can
acquire a reference to the new object and return it while its nulls node
is unhashed.
A PoC that drives reuse with a SYN cookie request socket reproduced the
crash. The new request socket is unhashed and has a NULL rsk_listener.
A lookup that had loaded the address of the old request socket acquired
the reference published by tcp_get_cookie_sock() and returned the new
object. tcp_v4_rcv() then read sk_state through the NULL listener.
The resulting crash was:
BUG: kernel NULL pointer dereference, address: 0000000000000012
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
...
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.3.0-00591-g0e135910deec #1 PREEMPT(lazy)
...
RIP: 0010:tcp_v4_rcv+0x44e/0x1280
...
R10: 0000000000000001 R11: 00000000024ca8c0 R12: 0000000000000000
...
CR2: 0000000000000012 CR3: 0000000103d50004 CR4: 0000000000770ef0
...
Call Trace:
IRQ
? raw_local_deliver+0xae/0x240
ip_protocol_deliver_rcu+0x2d/0x180
ip_local_deliver_finish+0x84/0x100
ip_sublist_rcv_finish+0x5f/0x70
ip_sublist_rcv+0x12a/0x1d0
ip_list_rcv+0xfd/0x130
__netif_receive_skb_list_core+0x223/0x250
netif_receive_skb_list_internal+0x1d2/0x2c0
? try_fill_recv+0x39/0x7b0
napi_complete_done+0x74/0x170
virtnet_poll+0x445/0x600
__napi_poll+0x27/0x1e0
net_rx_action+0x2fe/0x3b0
handle_softirqs+0xc2/0x2c0
__irq_exit_rcu+0x74/0xd0
common_interrupt+0x7f/0x90
...
Kernel panic - not syncing: Fatal exception in interrupt
After taking a reference, check whether the nulls node is unhashed in
both IPv4 and IPv6 established lookups. If it is unhashed or the tuple
no longer matches, drop the reference and restart the lookup.
Lookups racing with the TIME_WAIT hashdance, or with a request being
replaced by its child, now restart and find the new socket instead of
returning the old one.
Request sockets that were never inserted into ehash can have a nonzero
refcount, and a stale lookup can hold a transient reference. Therefore,
when SYN cookie, Fast Open, and request migration paths fail after
setting a nonzero refcount, release the references held by those paths
with reqsk_put() instead of freeing the request directly.
-
CVE-2026-99287
•
published on November 10, 2026
In the Linux kernel, the following vulnerability has been resolved:
xen-netback: Zero out sring pointers on unmap
If xenvif_map_frontend_data_rings() fails when a ring is already mapped,
it unmaps them via xenvif_unmap_frontend_data_rings() which keeps the
ring pointers unchanged. xenvif_connect_data()'s cleanup path calls
xenvif_disconnect_queue() which in turn calls
xenvif_unmap_frontend_data_rings() again, which will attempt to unmap the
pointers a second time.
Zero out the ring pointers after they are unmapped to avoid this issue.
This is XSA-532
-
CVE-2026-99286
•
published on November 10, 2026
In the Linux kernel, the following vulnerability has been resolved:
xen-netback: Fix XenBus connection failure cleanup
xenvif_get_stats and xenvif_get_ethtool_stats capture vif-num_queues
under rcu_read_lock. We need to unpublish vif->num_queues before
synchronize_net to ensure that readers that come afterwards will not
read a non-zero vif->num_queues and attempt to access invalid queues.
This is the same cleanup algorithm as used in backend_disconnect and
added in commit b17075d5c198 ("xen-netback: fix race condition on XenBus
disconnect").
This is XSA-531
-
CVE-2026-99285
•
published on November 10, 2026
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_byteorder: remove multi-register support
64bit byteorder conversion is broken when several registers need to be
converted because the source register array advances in steps for 4 bytes
instead of 8:
for (i = ...
src64 = nft_reg_load64(&src[i]);
~~~~~ u32 *src
nft_reg_store64(&dst64[i],
Remove the multi-register support, it has other issues as well:
Pablo points out that commit
caf3ef7468f7 ("netfilter: nf_tables: prevent OOB access in nft_byteorder_eval")
alters semantics: before the loop operated on registers, i.e.
for ( ... )
dst32[i] = htons((u16)src32[i])
.. but after the patch it will operate on bytes, which makes this
useless to convert e.g. concatenations, which store each compound
in its own register.
Multi-convert of u32 has one theoretical application:
ct mark . meta mark . tcp dport @intervalset
Because ct mark and meta mark are host byte order, use with
intervals has to convert the byteorder for ct/meta mark value
to network byte order (bigendian).
nftables emits this:
[ meta load mark = reg 1 ]
[ byteorder reg 1 = hton(reg 1, 4, 4) ]
[ ct load mark => reg 9 ]
[ byteorder reg 9 = hton(reg 9, 4, 4) ]
...
I.e. two separate calls. Theoretically it could be changed to do:
[ meta load mark => reg 1 ]
[ ct load mark => reg 9 ]
[ byteorder reg 1 = htonl(reg 1, 4, 8) ]
...
But then all it would take to change the set to
meta mark . tcp dport . ct mark
... and we'd be back to two "byteorder" calls. IOW, support to
convert a range of registers is both dysfunctional and dubious.
Simplify this: remove the feature.
Pablo Neira Ayuso points out that nftables before 1.1.0 can generate
incorrect byteorder conversions, see 9fe58952c45a,
"evaluate: skip byteorder conversion for selector smaller than 2 bytes"
in nftables.git). Affected rulesets fail to load with this change and
old userspace due to 'len != size' check.
-
CVE-2026-99284
•
published on November 7, 2026
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker in skb_zerocopy()
skb_zerocopy() moves frag descriptors from @from into @to and takes a
reference on each frag, but it does not copy skb_shinfo(from)-flags into
skb_shinfo(to)->flags. A destination skb holding the same page-cache
backed frags as the source therefore reports skb_has_shared_frag() as
false.
That breaks the invariant relied on by later in-place writers. ESP input
checks skb_has_shared_frag() before deciding whether an uncloned
nonlinear skb can skip skb_cow_data(); with the marker lost, an skb that
skb_zerocopy() built for nfnetlink_queue or for an openvswitch upcall is
decrypted in place, letting an unprivileged user write into the page
cache of a root-owned read-only file.
Propagate SKBFL_SHARED_FRAG when frag descriptors are copied, as done for
the other frag-transfer helpers.
-
CVE-2026-99283
•
published on November 7, 2026
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST
matches exact sequence") keeps an established conntrack entry in
ESTABLISHED when an in-window RST does not match the expected sequence
number exactly, so the endpoint can validate the RST with a challenge
ACK.
The timeout selection nevertheless uses the CLOSE timeout for every RST
packet. The bug is that timeout selection is based on the packet type,
not on the state transition result: even when RST validation keeps
new_state in ESTABLISHED, the timeout is still forced to
TCP_CONNTRACK_CLOSE.
Linux TCP independently rate limits challenge ACKs per socket. A second
non-exact RST can therefore arrive after the first challenge ACK has
restored the timeout but before the rate limit expires. The second RST
lowers the timeout to 10 seconds again while the endpoint suppresses the
second challenge ACK, allowing the conntrack entry to expire while both
TCP endpoints remain established.
Using the ESTABLISHED timeout for such RSTs would avoid this short
expiration window, but it could also retain stale entries for the
five-day default because conntrack cannot reliably match the endpoint's
exact TCP state.
Use the UNACK timeout for RST packets that leave the conntrack entry in
TCP_CONNTRACK_ESTABLISHED. Exact-match RSTs and accepted RST packet
trains still fall through to timeouts[new_state], which preserves the
CLOSE timeout when conntrack accepts the RST as closing the flow.
This avoids the aggressive 10-second expiration window for non-exact
RSTs while preserving the short timeout for RSTs that conntrack accepts
as closing the flow.
-
CVE-2026-99282
•
published on November 7, 2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_teql: fix use-after-free on lower qdisc drop
The issue: teql_master_xmit() tests the slave's ndo_start_xmit() return
value against NETDEV_TX_OK alone. A slave that consumes the skb but
returns an error code (rc NET_XMIT_MASK, e.g. NET_XMIT_DROP) is treated
as if the skb were still owned, so the loop restores skb-dev and calls
__skb_pull() on it. A VLAN slave returns the result of dev_queue_xmit()
from its ndo_start_xmit() (propagated since cbbef5e18307), and when the
lower qdisc drops the packet that value is NET_XMIT_DROP after the skb
has been freed, giving a use-after-free in teql_master_xmit().
The Fix: test for consumption with dev_xmit_complete(), which accepts
NETDEV_TX_OK and every rc < NET_XMIT_MASK, matching other callers that
need to distinguish consumed results from busy. Only NETDEV_TX_OK keeps
the packet counted in tx_packets/tx_bytes and advances the slave; a
consumed result that is neither a success nor NET_XMIT_CN ends the
attempt and is charged to tx_dropped, so lower-qdisc drops are no longer
reported as good transmits. NET_XMIT_CN is counted like success because
it can accompany acceptance of the current packet: pfifo_head_drop drops
the old head, enqueues the current skb and returns NET_XMIT_CN.
Conditions to recreate the bug:
With CONFIG_NET_SCH_TEQL,
CONFIG_VLAN_8021Q and CONFIG_DUMMY enabled, add lkrdummy0 (dummy) and
lkrvlan0 (VLAN id 37 on lkrdummy0); set a pfifo limit 0 root on lkrdummy0
and a teql0 root on lkrvlan0; bring teql0 up with an address and send one
UDP packet to it. The VLAN xmit returns NET_XMIT_DROP from the lower
qdisc while holding a freed skb.
-
CVE-2026-99281
•
published on November 7, 2026
In the Linux kernel, the following vulnerability has been resolved:
tun: Require CAP_NET_ADMIN to attach to an ownerless device
Twenty years ago I made creating a tuntap device require CAP_NET_ADMIN
in commit ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap
devices.")
The idea was to allow the permissions on /dev/net/tun to be relaxed to
0666 and thus allow owners of tun devices assigned with TUNSETOWNER to
actually open it and get at their devices.
What we missed at the time was that persistent devices with *no* owner
were already essentially world-consumable, and anyone who could open
the device node could also attach to those.
Even then, using persistent devices with no explicitly set owner — on
the (false) presumption that CAP_NET_ADMIN would be required to open
them — wasn't an egregious userspace bug. There are cases where it does
make sense to separate the creation/configuration of the netdevice, from
the process which shovels packets into it.
Since then, TUNSETGROUP was added a year later in commit 8c644623fe7e
("[NET]: Allow group ownership of TUN/TAP devices."). Its commit message
noted that if both uid and gid are set, both have to match (in itself a
bizarre choice) — but still not that with *neither* set, no permission
at all was required.
Then in 2012 commit c8d68e6be1c3 ("tuntap: multiqueue support") allowed
new queues to be attached to a device from the moment of its creation,
with no way for userspace to close the race between creation and a
subsequent TUNSET{OWNER,GROUP}.
In 2024, commit 3ca459eaba1bf ("tun: fix group permission check") tried
to fix things to be saner: only require the user *or* the group to
match, in line with standard POSIX permissions, and require
CAP_NET_ADMIN if neither the user nor group authorised the access
(although it put the CAP_NET_ADMIN check first, and would wrongly have
reported the capability as having been used even when it was not).
That fix was reverted in commit a70c7b3cbc06 ("tun: revert fix group
permission check") due to allegedly causing a regression in an selinux
test suite which *expected* the attachment to succeed when authorised
by none of user, group, nor CAP_NET_ADMIN:
https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/
We should not break UAPI. But we don't have to consider an selinux test
case which deliberately exercises a security flaw to be UAPI worth
preserving either. To which end, I have fixed it in selinux-testsuite
commit b2f894f0016b ("tests/tun_tap: set an owner on the device for the
relabel tests").
So: fix the lack of CAP_NET_ADMIN check on devices which *haven't* been
assigned an owner or group, while leaving the weird tun ownership model
as it was (user *and* group have to match, if both are set). If someone
still wants to fix the latter (which wasn't actually the reason the
previous attempt was reverted), they can do it under separate cover.
Permit attaching to an existing device only if an owner and/or group was
set and the caller matches all that were set, or if the caller has
CAP_NET_ADMIN. The only behavioural change is that a device with no
owner or group now requires CAP_NET_ADMIN to attach — precisely the
loophole we want to close.
And put the CAP_NET_ADMIN check in the right place this time.
-
CVE-2026-99280
•
published on November 7, 2026
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: drain session procfs readers before dropping table references
Session registration failure and connection cleanup can drop the table
reference while the per-session procfs entry is still accessible. If a
reader holds the last remaining reference, its final put calls
proc_remove() from its own callback and waits for that callback to
finish.
Remove the procfs entry before dropping the table reference in the
registration failure path. Queue sessions removed during connection
cleanup and drain their procfs readers after releasing both session
locks, then return their table references. Keep the global hash node
unhashed while a session is queued so a concurrent unregister cannot
drop the reference again.
Previous-session replacement also destroys the file table before the
session is finally freed. Detach the idr under the lock used by procfs
file counters, and report zero files after it has been detached. This
prevents a reader from accessing the idr during or after its
destruction.
-
CVE-2026-99279
•
published on November 7, 2026
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: reclaim ended sessions on logoff and expiration
LOGOFF and previous-session replacement leave sessions Expired with a
zero credential expiry. Ended sessions can retain their memory and
connection slots when no further setup arrives on the owning connection.
Unpublish a logged-off session while the request reference keeps its
response signing and encryption keys alive. Remove its procfs entry
before dropping the table reference so a reader cannot remove its own
entry on the last put. Clear proc_entry after removal to avoid removing
it twice.
Reclaim ended sessions from the global table in the existing expiration
worker before it acquires conn_list_lock. Only select Expired sessions
with zero credential expiry and no references beyond the table
reference. Keep sessions whose Kerberos credentials expired available
for reauthentication.
Unlink the session from its setup connection and all channel
connections, so SMB2 sessions and sessions with only secondary SMB3
channels are covered. The session already holds connection references,
and sessions_table_lock prevents concurrent channel removal. Queue
sessions on a separate disposal list, leaving their hash nodes unhashed,
and remove procfs entries and drop table references outside the locks.
Keep the pending setup check before allocating a new session so
abandoned InProgress sessions can release their slots even at the
connection limit. Retain the timeout and reference checks and dispose of
those sessions outside the locks. Leave ended Expired sessions to the
expiration worker.
-
CVE-2026-99278
•
published on November 7, 2026
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: limit sessions on each connection
The pending setup limit only counts InProgress sessions. A client can
complete authentication repeatedly and retain an unbounded number of Valid
sessions on one connection.
Reserve a connection slot before allocating a session and retain a
connection reference while authentication is in progress. The first SMB3
channel takes over that reservation; binding to another connection reserves
one slot there. Reauthentication and authentication continuation reuse the
existing reservation. Return slots on allocation or insertion failure,
channel removal, and final session destruction.
Accept max_sessions_per_connection in reserved startup-request space and
default to 64 when older tools leave it zero. Keep the request size and
existing field offsets unchanged. Expose the configured limit in procfs.
The existing connection limits bound the aggregate number of sessions
without a separate global session allocation limit.
