🚨 CVE-2026-42492
Xenstore, to have an up-to-date picture of the entire system, wants to
know of domains appearing and disappearing. To make this more robust, a
new XEN_DOMCTL_get_domain_state was introduced. The management of the
bitmap underlying that operation is tied into the binding of the
VIRQ_DOM_EXC virtual IRQ. Unfortunately an error path there would tear
down the bitmap even in cases when it wasn't set up. Unprivileged domains
can trigger that error path.
🎖@cveNotify
Xenstore, to have an up-to-date picture of the entire system, wants to
know of domains appearing and disappearing. To make this more robust, a
new XEN_DOMCTL_get_domain_state was introduced. The management of the
bitmap underlying that operation is tied into the binding of the
VIRQ_DOM_EXC virtual IRQ. Unfortunately an error path there would tear
down the bitmap even in cases when it wasn't set up. Unprivileged domains
can trigger that error path.
🎖@cveNotify
🚨 CVE-2026-42493
Addressing certain issues, in particular related to operations which may
take excessively long and therefore would need preemption, has turned out
overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly
available, the decision was to deprecate the functionality, while still
retaining it for people to use at their own (security) risk. Memory-wise
small enough guests may still be okay to run.
🎖@cveNotify
Addressing certain issues, in particular related to operations which may
take excessively long and therefore would need preemption, has turned out
overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly
available, the decision was to deprecate the functionality, while still
retaining it for people to use at their own (security) risk. Memory-wise
small enough guests may still be okay to run.
🎖@cveNotify
🚨 CVE-2026-42494
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
🚨 CVE-2026-42495
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
🚨 CVE-2026-49332
A flaw was found in openshift/oauth-proxy. The proxy sets authenticated identity headers using only dash-variant keys (X-Forwarded-User) but does not strip underscore-variant keys (X_Forwarded_User) from incoming requests. WSGI and PHP frameworks normalize both variants to the same variable, allowing an authenticated low-privilege user to smuggle a forged identity that may override the legitimate authenticated identity in the upstream application.
🎖@cveNotify
A flaw was found in openshift/oauth-proxy. The proxy sets authenticated identity headers using only dash-variant keys (X-Forwarded-User) but does not strip underscore-variant keys (X_Forwarded_User) from incoming requests. WSGI and PHP frameworks normalize both variants to the same variable, allowing an authenticated low-privilege user to smuggle a forged identity that may override the legitimate authenticated identity in the upstream application.
🎖@cveNotify
🚨 CVE-2026-62423
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
🚨 CVE-2026-62424
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
🚨 CVE-2026-62425
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425.
🎖@cveNotify
🚨 CVE-2026-62426
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
To manage the system, sysctl and platform operations are used by the
control domain or a possible Xenstore domain. Some of these operations
may not be executed in parallel, so a system-wide lock each is used.
The way those locks are acquired is, however, not providing any fairness.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking.
The sysctl issue is CVE-2026-62426.
The platform-op issue is CVE-2026-62427.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
To manage the system, sysctl and platform operations are used by the
control domain or a possible Xenstore domain. Some of these operations
may not be executed in parallel, so a system-wide lock each is used.
The way those locks are acquired is, however, not providing any fairness.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking.
The sysctl issue is CVE-2026-62426.
The platform-op issue is CVE-2026-62427.
🎖@cveNotify
🚨 CVE-2026-62427
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
To manage the system, sysctl and platform operations are used by the
control domain or a possible Xenstore domain. Some of these operations
may not be executed in parallel, so a system-wide lock each is used.
The way those locks are acquired is, however, not providing any fairness.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking.
The sysctl issue is CVE-2026-62426.
The platform-op issue is CVE-2026-62427.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
To manage the system, sysctl and platform operations are used by the
control domain or a possible Xenstore domain. Some of these operations
may not be executed in parallel, so a system-wide lock each is used.
The way those locks are acquired is, however, not providing any fairness.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking.
The sysctl issue is CVE-2026-62426.
The platform-op issue is CVE-2026-62427.
🎖@cveNotify
🚨 CVE-2026-62428
When grant-copy operations are processed, the respective grant may or may
not already be in use by another operation (a mapping or another copy).
For all copy operations the referenced guest frame is looked up. When
another operation is already active for the grant (the grant is "pinned"),
what is being supplied back to actually carry out permission checks and
copy operation may not be consistent: The permission check may be carried
out on a page different from the one involved in the copy.
🎖@cveNotify
When grant-copy operations are processed, the respective grant may or may
not already be in use by another operation (a mapping or another copy).
For all copy operations the referenced guest frame is looked up. When
another operation is already active for the grant (the grant is "pinned"),
what is being supplied back to actually carry out permission checks and
copy operation may not be consistent: The permission check may be carried
out on a page different from the one involved in the copy.
🎖@cveNotify
🚨 CVE-2026-62429
Accessing the vNUMA configuration data of a guest is still possible when
domain destruction has already started. The cleaning up of that
configuration information is not synchronized with its retrieval by a
device model controlling the guest.
🎖@cveNotify
Accessing the vNUMA configuration data of a guest is still possible when
domain destruction has already started. The cleaning up of that
configuration information is not synchronized with its retrieval by a
device model controlling the guest.
🎖@cveNotify
🚨 CVE-2026-62431
The logic to handle periodic Viridian STIMERs performs a division with an
unchecked user-controlled divisor value, that can be set to zero to cause a #DE
fault.
🎖@cveNotify
The logic to handle periodic Viridian STIMERs performs a division with an
unchecked user-controlled divisor value, that can be set to zero to cause a #DE
fault.
🎖@cveNotify
🚨 CVE-2026-62432
The EVTCHNOP_expand_array hypercall checks for whether FIFO event
channels are enabled, but without holding the correct lock. It can race
with EVTCHNOP_reset, resulting in dereferencing a NULL pointer.
🎖@cveNotify
The EVTCHNOP_expand_array hypercall checks for whether FIFO event
channels are enabled, but without holding the correct lock. It can race
with EVTCHNOP_reset, resulting in dereferencing a NULL pointer.
🎖@cveNotify
🚨 CVE-2026-62433
Parts of the DM_OP handling code assumes the caller has provided the
required number of buffers for the given operation without any checking
being done. As a result, certain operations might access stack
rubble as structures are possibly uninitialized.
🎖@cveNotify
Parts of the DM_OP handling code assumes the caller has provided the
required number of buffers for the given operation without any checking
being done. As a result, certain operations might access stack
rubble as structures are possibly uninitialized.
🎖@cveNotify
🚨 CVE-2026-62434
A guest started with Populated on Demand enabled (PoD) can attempt to
reclaim pages which aren't regular guest RAM. This can cause corruption
of memory management state in Xen.
🎖@cveNotify
A guest started with Populated on Demand enabled (PoD) can attempt to
reclaim pages which aren't regular guest RAM. This can cause corruption
of memory management state in Xen.
🎖@cveNotify
🚨 CVE-2026-62435
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
With the introduction of Grant Table v2 came the requirement to be able to
switch between versions. Switching from v1 to v2 reduces the number of
valid grant references, as a bigger shared entry structure is then needed
while the shared table doesn't change size. Switching from v2 back to v1
the status frames, which are separate in v2, go away.
Code holding, but intermediately dropping and then re-acquiring the grant
table lock, sometimes wrongly assumes that said properties wouldn't change
across the window in time where the lock is not being held.
The v1 -> v2 issue is CVE-2026-62435.
The v2 -> v1 issue is CVE-2026-62436.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
With the introduction of Grant Table v2 came the requirement to be able to
switch between versions. Switching from v1 to v2 reduces the number of
valid grant references, as a bigger shared entry structure is then needed
while the shared table doesn't change size. Switching from v2 back to v1
the status frames, which are separate in v2, go away.
Code holding, but intermediately dropping and then re-acquiring the grant
table lock, sometimes wrongly assumes that said properties wouldn't change
across the window in time where the lock is not being held.
The v1 -> v2 issue is CVE-2026-62435.
The v2 -> v1 issue is CVE-2026-62436.
🎖@cveNotify
🚨 CVE-2026-62436
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
With the introduction of Grant Table v2 came the requirement to be able to
switch between versions. Switching from v1 to v2 reduces the number of
valid grant references, as a bigger shared entry structure is then needed
while the shared table doesn't change size. Switching from v2 back to v1
the status frames, which are separate in v2, go away.
Code holding, but intermediately dropping and then re-acquiring the grant
table lock, sometimes wrongly assumes that said properties wouldn't change
across the window in time where the lock is not being held.
The v1 -> v2 issue is CVE-2026-62435.
The v2 -> v1 issue is CVE-2026-62436.
🎖@cveNotify
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
With the introduction of Grant Table v2 came the requirement to be able to
switch between versions. Switching from v1 to v2 reduces the number of
valid grant references, as a bigger shared entry structure is then needed
while the shared table doesn't change size. Switching from v2 back to v1
the status frames, which are separate in v2, go away.
Code holding, but intermediately dropping and then re-acquiring the grant
table lock, sometimes wrongly assumes that said properties wouldn't change
across the window in time where the lock is not being held.
The v1 -> v2 issue is CVE-2026-62435.
The v2 -> v1 issue is CVE-2026-62436.
🎖@cveNotify
🚨 CVE-2026-65881
Joomla Extension - joomdle.com - Insecure default configuration allows read/write user account access in Joomdle < 3.1.1 - The default configuration of the extension allowed read access and password reset of CMS accounts.
🎖@cveNotify
Joomla Extension - joomdle.com - Insecure default configuration allows read/write user account access in Joomdle < 3.1.1 - The default configuration of the extension allowed read access and password reset of CMS accounts.
🎖@cveNotify
Joomdle
Joomdle - Home
Joomdle connects Moodle, the worlds most common learning management system with Joomla, the worlds best content management system.
🚨 CVE-2026-65882
Joomla Extension - joomdle.com - Reflected XSS vulnerability in Joomdle < 3.1.1 - The goto url parameter of the moodle wrapper endpoint allowed a reflected XSS vector.
🎖@cveNotify
Joomla Extension - joomdle.com - Reflected XSS vulnerability in Joomdle < 3.1.1 - The goto url parameter of the moodle wrapper endpoint allowed a reflected XSS vector.
🎖@cveNotify
Joomdle
Joomdle - Home
Joomdle connects Moodle, the worlds most common learning management system with Joomla, the worlds best content management system.
🚨 CVE-2026-66913
Lookyloo did not enforce limits on the decompressed size of uploaded capture archives and compressed HAR files.
An attacker could submit a specially crafted ZIP, gzip, or zlib-compressed capture containing data that expands to a very large size during processing. Because the application decompressed this content directly in memory without first limiting the output size, processing the malicious capture could exhaust available memory, terminate a web or worker process, or make the Lookyloo instance unavailable.
The vulnerability affects both full Lookyloo capture archive imports and API submissions containing gzip-compressed HAR data. Repeated exploitation could cause a persistent denial-of-service condition until the affected processes or instance are restarted.
The patch introduces:
* A 1 GB cumulative uncompressed-size limit for imported capture archives.
* Size-limited gzip and zlib decompression for compressed HAR files.
* Explicit detection and handling of suspected zip bombs.
* An HTTP 400 response when an oversized compressed HAR file is submitted through the API.
🎖@cveNotify
Lookyloo did not enforce limits on the decompressed size of uploaded capture archives and compressed HAR files.
An attacker could submit a specially crafted ZIP, gzip, or zlib-compressed capture containing data that expands to a very large size during processing. Because the application decompressed this content directly in memory without first limiting the output size, processing the malicious capture could exhaust available memory, terminate a web or worker process, or make the Lookyloo instance unavailable.
The vulnerability affects both full Lookyloo capture archive imports and API submissions containing gzip-compressed HAR data. Repeated exploitation could cause a persistent denial-of-service condition until the affected processes or instance are restarted.
The patch introduces:
* A 1 GB cumulative uncompressed-size limit for imported capture archives.
* Size-limited gzip and zlib decompression for compressed HAR files.
* Explicit detection and handling of suspected zip bombs.
* An HTTP 400 response when an oversized compressed HAR file is submitted through the API.
🎖@cveNotify
GitHub
fix: Zip Bomb when uploading a capture. · Lookyloo/lookyloo@96589da
Thank you @EQSTLab for the report!