In Apache Iceberg, the table's metadata files are control files: they tell readers
which data files belong to the table and which table version to read.
`write.metadata.path` is an optional table property that tells Polaris
where to
write those metadata files.
For a table already registered in a
Polaris-managed
catalog, changing only that property through an `ALTER TABLE`-style settings
change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses
the commit-time branch that is supposed to revalidate storage locations.
The full persisted / credential-vending variant requires the affected
catalog
to have `polaris.config.allow.unstructured.table.location=true`, with
`allowedLocations` broad enough to include the attacker-chosen target.
`allowedLocations` is the admin-configured allowlist of storage paths that
the
catalog is allowed to use. Public project materials suggest that this flag
is a
real supported compatibility / layout mode, not just a contrived lab-only
prerequisite.
In that configuration, a user who can change table settings can cause Apache Polaris
itself to write new table metadata to an attacker-chosen reachable storage
location before the intended location-validation branch runs.
If the later concrete-path validation also accepts that location, Polaris
persists the resulting metadata path into stored table state. Later
table-load
and credential APIs can then return temporary cloud-storage credentials for
the
same location without revalidating it. In plain terms, Polaris can later
hand
out temporary storage access for the same attacker-chosen area.
That attacker-chosen area does not need to be limited to the poisoned
table's
own files. If it is a broader storage prefix, another table's prefix, or,
depending on configuration or provider behavior, even a bucket/container
root,
the resulting disclosure or corruption scope can extend to any data and
metadata Polaris can reach there.
The practical consequences are therefore similar to the staged-create
credential-vending issue already discussed: data and metadata reachable in
that
storage scope can be exposed and, if write-capable credentials are later
issued, modified, corrupted, or removed. Even before that later credential
step, Polaris itself performs the metadata write to the unchecked location.
So the core issue is not only later credential vending.
The primary defect
is
that Polaris skips its intended location checks before performing a
security-
sensitive metadata write when only `write.metadata.path` changes.
When `polaris.config.allow.unstructured.table.location=false`, current code
review suggests the later `updateTableLike(...)` validation usually rejects
out-of-tree metadata locations before the unsafe path is persisted. That may
reduce the persisted / credential-vending variant, but it does not prevent
the
underlying defect: Polaris still skips the intended pre-write location check
when only `write.metadata.path` changes.
IBM i 7.6, 7.5, 7.4, 7.3, and 7.2 s vulnerable to privilege escalation caused by an invalid IBM i Web Administration GUI authorization check. A malicious actor could cause user-controlled code to run with administrator privilege.
Chartbrew version 4.9.0 contains an improper access control vulnerability where a legacy dashboard route exposes project report data to any authenticated team member, regardless of their project access rights. This flaw allows low-privileged users within the same team to access another project's dashboard data, including sensitive stored report passwords. The vulnerability has been fixed in version 5.0.0.
Chartbrew version 4.9.0 contains an improper access control vulnerability that allows unauthenticated attackers to access chart data that should be hidden. The application exposes public chart retrieval and export routes that verify only project-level public access and a team-level export toggle, but do not verify if the specific chart is allowed on the public report or if the SharePolicy permits public access. This flaw enables attackers who know a chart identifier in a public project to read or export data from charts intentionally hidden from public reports. The issue was fixed in version 5.0.0.
Chartbrew version 4.9.0 contains an improper access control vulnerability where dataset and dataRequest endpoints authorize users at the team level rather than restricting access to specific projects. This allows authenticated users with access to one project to manipulate datasets and data requests of other projects within the same team. The vulnerability enables unauthorized reading, execution, creation, updating, and deletion of data, leading to cross-project data disclosure and misuse of database or API connections. The issue is fixed in version 5.0.0.
Improper Privilege Management, Improper Access Control, Incorrect privilege assignment vulnerability in TUBITAK BILGEM Software Technologies Research Institute Pardus Software Center allows Hijacking a privileged process.
This issue affects Pardus Software Center: from 1.0.2 before 1.0.3.
An insecure direct object reference (IDOR) vulnerability in MphRx's Minerva V3.6.0, specifically in the endpoint '/minerva/moUser/show/'. If this vulnerability is successfully exploited, an authenticated user can access the data of other registered users simply by modifying the ID. This allows an attacker to obtain a list of users.
An insecure direct object reference (IDOR) vulnerability in MphRx's Minerva V3.6.0, specifically in the '/minerva/user/updateUserProfile' endpoint. This allows an authenticated user to modify the information of other registered users. Successful exploitation of this vulnerability allows an authenticated user to modify other users' information, such as their email address, and request a new password via the '/webconnect/#/forgotPassword' endpoint. This could lead to complete account takeover.
In Spring AI, an attacker can bypass conversation isolation and exfiltrate sensitive memory from other users’ chat histories, including secrets and credentials, by injecting filter logic through conversationId. Only applications that use VectorStoreChatMemoryAdvisor and pass user-supplied input as a conversationId are affected.
A vulnerability was found in GreenCMS up to 2.3. Affected is the function themeadd of the file /index.php?m=admin&c=custom&a=themeadd. The manipulation results in unrestricted upload. The attack can be launched remotely. The exploit has been made public and could be used. This vulnerability only affects products that are no longer supported by the maintainer.
CVE-2026-7043 is a medium severity vulnerability in GreenCMS versions up to 2.3 that allows unrestricted file upload via the pluginAddLocal function in the /index.php? m=admin&c=custom&a=pluginadd endpoint. This vulnerability can be exploited remotely without user interaction and affects only unsupported versions of GreenCMS. No official patch or remediation is available from the maintainer. The vulnerability has been publicly disclosed, but there are no confirmed exploits in the wild at this time.
CVE-2026-7041 is an information disclosure vulnerability in 666ghj MiroFish versions up to 0.1.2. It affects an unknown function in the Werkzeug Debugger PIN Handler component, specifically in the /console file. The vulnerability can be triggered remotely by manipulating the SECRET argument. Exploitation is considered difficult due to high attack complexity. Although the exploit is publicly available, there is no vendor response or patch at this time. The CVSS 4.0 base score is 6.3, indicating medium severity.
A weakness has been identified in SmythOS sre up to 0.0.15. This impacts an unknown function of the file packages/sdk/src/LLM/utils.ts of the component Connector Service. This manipulation of the argument baseURL causes information disclosure. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
Actual is a local-first personal finance tool. Prior to version 26.4.0, any authenticated user (including `BASIC` role) can escalate to `ADMIN` on servers migrated from password authentication to OpenID Connect. Three weaknesses combine: `POST /account/change-password` has no authorization check, allowing any session to overwrite the password hash; the inactive password `auth` row is never removed on migration; and the login endpoint accepts a client-supplied `loginMethod` that bypasses the server's active auth configuration. Together these allow an attacker to set a known password and authenticate as the anonymous admin account created during the multiuser migration. The three weaknesses form a single, sequential exploit chain — none produces privilege escalation on its own. Missing authorization on POST /change-password allows overwriting a password hash, but only matters if there is an orphaned row to target. Orphaned password row persisting after migration provides the target row, but is harmless without the ability to authenticate using it. Client-controlled loginMethod: "password" allows forcing password-based auth, but is useless without a known hash established by step 1. All three must be chained in sequence to achieve the impact. No single weakness independently results in privilege escalation. The single root cause is the missing authorization check on /change-password; the other two are preconditions that make it exploitable. Version 26.4.0 contains a fix.
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, a Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities. Because the service uses repository.save() with a client-supplied primary key, the POST create endpoint behaves as an implicit UPSERT operation. This enables overwriting existing DocumentStore objects. In multi-workspace or multi-tenant deployments, this can lead to cross-workspace object takeover and broken object-level authorization (IDOR), allowing an attacker to reassign or modify DocumentStore objects belonging to other workspaces. This vulnerability is fixed in 3.1.0.
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, a Server-Side Request Forgery (SSRF) protection bypass vulnerability exists in the Custom Function feature. While the application implements SSRF protection via HTTP_DENY_LIST for axios and node-fetch libraries, the built-in Node.js http, https, and net modules are allowed in the NodeVM sandbox without equivalent protection. This allows authenticated users to bypass SSRF controls and access internal network resources (e.g., cloud provider metadata services) This vulnerability is fixed in 3.1.0.
CVE-2026-41243 is an improper access control vulnerability in the open-source forum software OpenLearn by siemvk. Before a specific code commit (844b2a40a69d0c4911580fe501923f0b391313ab), when safeMode was enabled, unapproved forum posts were hidden from public listings but could still be accessed directly by anyone with the post UUID. This allowed unauthorized users to read posts that should have been restricted. The issue was fixed in the referenced commit.
CVE-2026-40889 is an improper access control vulnerability in Frappe HRMS versions prior to 15.58.2 and 16.4.2. Authenticated users can exploit certain API endpoints to access unauthorized files. The issue is resolved in versions 15.58.2 and 16.4.
Frappe HR is an open-source human resources management solution (HRMS). Prior to versions 15.58.1 and 16.4.1, an authenticated user with default role can access unauthorized information by exploiting certain api endpoint. Versions 15.58.1 and 16.4.1 contain a patch. No known workarounds are available.