Vulnerabilidades

*** Pendiente de traducción *** In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials<br /> that<br /> only work for one table&amp;#39;s files, but a crafted namespace or table name can<br /> cause those credentials to work across the configured bucket instead.<br /> <br /> <br /> Apache Polaris builds Google Cloud Storage downscoped credentials by creating a<br /> Credential Access Boundary (CAB) with CEL conditions that are intended to<br /> restrict access to the requested table&amp;#39;s storage path.<br /> <br /> <br /> <br /> The relevant CEL string is built from the bucket name and the table path.<br /> That<br /> table path is derived from namespace and table identifiers. In current code,<br /> that path appears to be inserted into the CEL expression without escaping.<br /> <br /> <br /> <br /> As a result, a namespace or table identifier containing a single quote and<br /> other URI-safe CEL fragments can break out of the intended quoted string and<br /> change the meaning of the CEL condition.<br /> <br /> <br /> <br /> In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated<br /> GCS<br /> credentials whose CEL path restriction had effectively collapsed.<br /> <br /> <br /> Those delegated credentials could then:<br /> <br /> <br /> - list another table&amp;#39;s object prefix;<br /> <br /> - read another table&amp;#39;s metadata control file (Iceberg metadata JSON);<br /> <br /> - create and delete an object under another table&amp;#39;s object prefix;<br /> <br /> - and also list, read, create, and delete objects under an unrelated<br /> external<br /> prefix in the same bucket that was not part of any table path.<br /> <br /> <br /> <br /> That last point is important. The issue is not limited to "another table".<br /> In<br /> the confirmed setup, once Apache Polaris returned credentials for the crafted<br /> table,<br /> the path restriction inside the configured bucket was effectively gone.<br /> <br /> The practical effect is that temporary credentials for one crafted table<br /> can be<br /> broader than the table Polaris was asked to authorize, and can become<br /> effectively bucket-wide within the configured bucket.<br /> <br /> <br /> <br /> The current GCS testing used a Polaris principal with broad catalog<br /> privileges for setup. A separate least-privilege Polaris RBAC variant<br /> has not yet been tested on GCS. However, the storage-credential<br /> broadening behavior itself has been confirmed on GCS.

*** Pendiente de traducción *** In Apache Iceberg, the table&amp;#39;s metadata files are control files: they tell readers<br /> which data files belong to the table and which table version to read.<br /> <br /> <br /> <br /> `write.metadata.path` is an optional table property that tells Polaris<br /> where to<br /> write those metadata files. <br /> For a table already registered in a<br /> Polaris-managed<br /> catalog, changing only that property through an `ALTER TABLE`-style settings<br /> change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses<br /> the commit-time branch that is supposed to revalidate storage locations.<br /> <br /> The full persisted / credential-vending variant requires the affected<br /> catalog<br /> to have `polaris.config.allow.unstructured.table.location=true`, with<br /> `allowedLocations` broad enough to include the attacker-chosen target.<br /> <br /> <br /> `allowedLocations` is the admin-configured allowlist of storage paths that<br /> the<br /> catalog is allowed to use. Public project materials suggest that this flag<br /> is a<br /> real supported compatibility / layout mode, not just a contrived lab-only<br /> prerequisite.<br /> <br /> <br /> In that configuration, a user who can change table settings can cause Apache Polaris<br /> itself to write new table metadata to an attacker-chosen reachable storage<br /> location before the intended location-validation branch runs.<br /> <br /> If the later concrete-path validation also accepts that location, Polaris<br /> persists the resulting metadata path into stored table state. Later<br /> table-load<br /> and credential APIs can then return temporary cloud-storage credentials for<br /> the<br /> same location without revalidating it. In plain terms, Polaris can later<br /> hand<br /> out temporary storage access for the same attacker-chosen area.<br /> <br /> That attacker-chosen area does not need to be limited to the poisoned<br /> table&amp;#39;s<br /> own files. If it is a broader storage prefix, another table&amp;#39;s prefix, or,<br /> depending on configuration or provider behavior, even a bucket/container<br /> root,<br /> the resulting disclosure or corruption scope can extend to any data and<br /> metadata Polaris can reach there.<br /> <br /> <br /> <br /> The practical consequences are therefore similar to the staged-create<br /> credential-vending issue already discussed: data and metadata reachable in<br /> that<br /> storage scope can be exposed and, if write-capable credentials are later<br /> issued, modified, corrupted, or removed. Even before that later credential<br /> step, Polaris itself performs the metadata write to the unchecked location.<br /> <br /> So the core issue is not only later credential vending. <br /> <br /> The primary defect<br /> is<br /> that Polaris skips its intended location checks before performing a<br /> security-<br /> sensitive metadata write when only `write.metadata.path` changes.<br /> <br /> <br /> <br /> When `polaris.config.allow.unstructured.table.location=false`, current code<br /> review suggests the later `updateTableLike(...)` validation usually rejects<br /> out-of-tree metadata locations before the unsafe path is persisted. That may<br /> reduce the persisted / credential-vending variant, but it does not prevent<br /> the<br /> underlying defect: Polaris still skips the intended pre-write location check<br /> when only `write.metadata.path` changes.

*** Pendiente de traducción *** OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader <br /> <br /> Versions Affected: <br /> <br /> before 2.5.9<br /> <br /> before 3.0.0-M3 <br /> <br /> Description:<br /> <br /> <br /> The AbstractModelReader methods getOutcomes(), getOutcomePatterns(), and getPredicates() each read a 32-bit signed integer count field from a binary model stream and pass that value directly to an array allocation (new String[numOutcomes], new int[numOCTypes][], new String[NUM_PREDS]) without validating that the value is non-negative or within a reasonable bound. The count is therefore fully attacker-controlled when the model file originates from an untrusted source.<br /> <br /> <br /> A crafted .bin model file in which any of these count fields is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) triggers an OutOfMemoryError at the array allocation itself, before the corresponding label or pattern data is consumed from the stream. The error occurs very early in deserialization: for a GIS model, getOutcomes() is reached after only the model-type string, the correction constant, and the correction parameter have been read; so the attacker pays no meaningful size cost to weaponize a payload, and a single small file can crash a JVM that loads it. Any code path that deserializes a .bin model is affected, including direct use of GenericModelReader and any higher-level component that delegates to it during model load.<br /> <br /> <br /> The practical impact is denial of service against processes that load model files from untrusted or semi-trusted origins.  <br /> <br /> <br /> Mitigation:<br /> <br /> <br /> <br /> * 2.x users should upgrade to 2.5.9.<br /> <br /> * 3.x users should upgrade to 3.0.0-M3.<br /> <br /> <br /> <br /> <br /> Note: The fix introduces an upper bound on each of the three count fields, checked before array allocation; counts that are negative or exceed the bound cause an IllegalArgumentException to be thrown and the read to fail fast with no large allocation. The default bound is 10,000,000, which is well above the entry counts of legitimate OpenNLP models but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load models with more entries than the default can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default.<br /> <br /> <br /> Users who cannot upgrade immediately should treat all .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.

*** Pendiente de traducción *** PPTAgent is an agentic framework for reflective PowerPoint generation. Prior to commit 418491a, there is an arbitrary file write vulnerability via `save_generated_slides`. This issue has been patched via commit 418491a.

*** Pendiente de traducción *** D-Link DIR-600L Hardware Revision A1 (End-of-Life) contains a hardcoded telnet backdoor. The device starts a telnet daemon at boot via /bin/telnetd.sh with the username "Alphanetworks" and the static password "wrgn35_dlwbr_dir600l" read from /etc/alpha_config/image_sign. The custom telnetd binary accepts a -u user:password flag, and the custom login binary uses strcmp() to validate credentials. Successful authentication grants an unauthenticated attacker on the local network a root shell with full administrative control. The device has reached End-of-Life (EOL) and will not receive patches.

*** Pendiente de traducción *** D-Link DIR-600L Hardware Revision B1 (End-of-Life) contains a hardcoded telnet backdoor. The device starts a telnet daemon at boot via /bin/telnetd.sh with the username "Alphanetworks" and the static password "wrgn61_dlwbr_dir600L" read from /etc/alpha_config/image_sign. The custom telnetd binary accepts a -u user:password flag, and the custom login binary uses strcmp() to validate credentials. Successful authentication grants an unauthenticated attacker on the local network a root shell with full administrative control.  The device has reached End-of-Life (EOL) and will not receive patches.

*** Pendiente de traducción *** D-Link DIR-605L Hardware Revision B2 (End-of-Life, EOL) contains a hardcoded telnet backdoor. The device starts a telnet daemon at boot via /bin/telnetd.sh with the username "Alphanetworks" and the static password "wrgn76_dlwbr_dir605L" read from /etc/alpha_config/image_sign. The custom telnetd binary accepts a -u user:password flag, and the custom login binary uses strcmp() to validate credentials. Successful authentication grants an unauthenticated attacker on the local network a root shell with full administrative control. The device has reached End-of-Life (EOL) and will not receive patches.

*** Pendiente de traducción *** D-Link DIR-605L Hardware Revision A1 (End-of-Life, EOL) contains a hardcoded telnet backdoor. The device starts a telnet daemon at boot via /bin/telnetd.sh with the username "Alphanetworks" and the static password "wrgn35_dlwbr_dir605l" read from /etc/alpha_config/image_sign. The custom telnetd binary accepts a -u user:password flag, and the custom login binary uses strcmp() to validate credentials. Successful authentication grants an unauthenticated attacker on the local network a root shell with full administrative control. The device has reached End-of-Life (EOL) and will not receive patches.

*** Pendiente de traducción *** Notesnook is a note-taking app focused on user privacy &amp; ease of use. Prior to Notesnook Web/Desktop version 3.3.15 and prior to Notesnook iOS/Android version 3.3.20, a stored XSS vulnerability in the note export flow can be escalated to remote code execution in the desktop app. The root cause is that exported note fields such as title, headline, and content are inserted into the generated HTML template without HTML escaping. When the note is later exported to PDF, Notesnook renders that HTML into a same-origin, unsandboxed iframe using iframe.srcdoc = .... Injected script executes in the Notesnook origin. In the desktop app, this becomes RCE because Electron is configured with nodeIntegration: true and contextIsolation: false. This issue has been patched in Notesnook Web/Desktop version 3.3.15 and Notesnook iOS/Android version 3.3.20.

*** Pendiente de traducción *** PPTAgent is an agentic framework for reflective PowerPoint generation. Prior to commit 418491a, PPTAgent is vulnerable to arbitrary file write and directory creation via markdown_table_to_image. This issue has been patched via commit 418491a.

*** Pendiente de traducción *** PPTAgent is an agentic framework for reflective PowerPoint generation. Prior to commit 418491a, PPTAgent is vulnerable to arbitrary code execution via Python eval() of LLM-generated code with builtins in scope. This issue has been patched via commit 418491a.

*** Pendiente de traducción *** Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader<br /> <br /> <br /> <br /> <br /> <br /> Versions Affected: before 2.5.9, before 3.0.0-M3<br /> <br /> <br /> <br /> <br /> <br /> Description: <br /> <br /> The ExtensionLoader.instantiateExtension(Class, String) method loads a class by its fully-qualified name via Class.forName() and invokes its no-arg constructor, with the class name sourced from the manifest.properties entry of a model archive. The existing isAssignableFrom check correctly rejects classes that are not subtypes of the expected extension interface (BaseToolFactory for factory=, ArtifactSerializer for serializer-class-*), but the check runs after Class.forName() has already loaded and initialized the named class. <br /> <br /> Class.forName() with default initialization semantics executes the target class&amp;#39;s static initializer before returning, so an attacker who can supply a crafted model archive can cause the static initializer of any class on the classpath to run during model loading, regardless of whether that class passes the subsequent type check. <br /> <br /> Exploitation requires a class with attacker-useful side effects in its static initializer (for example, JNDI lookup, outbound network I/O, or filesystem access) to be present on the classpath, so this is not a drop-in remote code execution; however, the attack surface grows as third-party model distribution becomes more common (community model repositories, Hugging Face-style sharing), where users routinely load model files from origins they do not control. A secondary, narrower vector affects deployments that ship legitimate BaseToolFactory or ArtifactSerializer subclasses with side-effecting no-arg constructors: a malicious manifest can name such a class and force its constructor to run during model load.<br /> <br /> <br /> <br /> <br /> <br /> Mitigation: <br /> <br /> <br /> <br /> * 2.x users should upgrade to 2.5.9. <br /> * 3.x users should upgrade to 3.0.0-M3. <br /> <br /> <br /> <br /> <br /> Note: The fix introduces a package-prefix allowlist that is consulted before Class.forName() is invoked, so the static initializer of a disallowed class is never executed. Classes under the opennlp. prefix remain permitted by default. Deployments that load models referencing factories or serializers outside opennlp.* must opt those packages in, either programmatically via ExtensionLoader.registerAllowedPackage(String) before the first model load, or by setting the OPENNLP_EXT_ALLOWED_PACKAGES system property to a comma-separated list of allowed package prefixes. <br /> <br /> Users who cannot upgrade immediately should ensure that all model files are sourced from trusted origins and should audit their classpath for classes with side-effecting static initializers or constructors, particularly any that perform JNDI lookups, network requests, or filesystem operations during class initialization.