CVE Watch8 de out. de 2026

CVE-2025-11371

Gladinet CentreStack and Triofox Files or Directories Accessible to External Parties Vulnerability

CVSS

7.5

Alta

EPSS

92.1%

p100

KEV

SIM

4 de nov. de 2025

Exploit Today

0-100

Publicado: 9 de out. de 2025 · Última mod.: 8 de out. de 2026 · CWE-552

EPSS · 30d

92.1%EPSS · 30 dias92.1%

2026-10-082026-11-05

Ficha do catálogo KEV

Produto

Gladinet / CentreStack and Triofox

Vulnerabilidade

Gladinet CentreStack and Triofox Files or Directories Accessible to External Parties Vulnerability

Adicionado ao KEV

4 de nov. de 2025

Corrigir até

25 de nov. de 2025

Uso conhecido em ransomware

Não

Descrição resumida

Gladinet CentreStack and Triofox contains a files or directories accessible to external parties vulnerability that allows unintended disclosure of system files.

Ação necessária

Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

Notas

https://www.centrestack.com/p/gce_latest_release.html ; https://nvd.nist.gov/vuln/detail/CVE-2025-11371

Descrição técnica

In the default installation and configuration of Gladinet CentreStack and TrioFox, there is an unauthenticated Local File Inclusion Flaw that allows unintended disclosure of system files. Exploitation of this vulnerability has been observed in the wild. This issue impacts Gladinet CentreStack and Triofox: All versions prior to and including 16.7.10368.56560

Referências oficiais

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-659837.5 ALT

—

——0OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.2.0, interface/modules/custom_modules/oe-module-faxsms/src/Controller/SignalWireClient.php decrypts a selected patient document with Document::get_data() and SignalWireClient::uploadFileForFax() writes the plaintext bytes under sites/{siteId}/fax. The module returns the resulting public URL to SignalWire, protects it only with a predictable uniqid() filename, and never removes the staged file. An unauthenticated network actor who obtains or guesses the URL can retrieve persistent patient documents even when drive encryption is enabled. This issue is fixed in version 8.2.0.4h CVE-2026-1231975.3 MÉD

—

——0WPPConnect Server through 2.10.76 contains a missing authentication vulnerability that allows unauthenticated attackers to read decrypted sticker media through the /files static mount. Attackers can enumerate Unix timestamps in GET /files/file<timestamp>.webp requests to retrieve stickers from any session, bypassing per-session token checks.5h CVE-2026-906325.5 MÉD

12.8%

——4Apache OpenOffice documents can include multimedia content (audio, video, etc.) A crafted document could exploit the GStreamer multimedia component of Apache OpenOffice version through 4.1.16 to load the contents of any local file, and include them when the document is saved or exported, for example as PDF. Users are recommended to upgrade to version 4.1.17, which fixes this issue.1d CVE-2026-906275.5 MÉD

6.2%

——2The flat file database driver in Apache Openoffice versions through 4.1.16 allows a crafted document to read the contents of any local file without asking the user. Users are recommended to upgrade to version 4.1.17, which fixes this issue.9h CVE-2026-1205015.3 MÉD

22.5%

——7An Otter Wiki 2.20.1 before 2.26.2 contains a file disclosure vulnerability in the DataTable embedding that allows attackers who can edit pages, including anonymous users under the default configuration, to read repository-internal files. Attackers can set an absolute src such as /.git/config to render the file as a table, exposing any stored remote credentials.3d CVE-2026-84172—

18.6%

——6Files accessible to external parties in Apache Wicket. org.apache.wicket.markup.html.PackageResourceGuard decides whether a file on the classpath may be streamed to a client as a package resource. HTML is on the default allow list, so the only thing that separates a static HTML file, which may be served, from a component's markup template, which may not, is a check for a class file of the same name beside it. That check calls getResource() on the class loader that loaded wicket-core. The resource itself is reached through different class loaders: the scope class is resolved through the application's IClassResolver, which uses the thread context class loader, and org.apache.wicket.core.util.resource.ClassPathResourceFinder#find() then tries the scope class' own loader, the context class loader, and the wicket-core loader last. Where wicket-core is loaded by a class loader that cannot see the application's classes, the check finds no class file, concludes the file is not a component markup template, and serves it. A request for the package resource URL of a component class then returns that component's markup template with status 200. What is disclosed is developer-authored template content: component structure, developer comments, markup that is rendered only under some conditions, inline script, and the endpoints a template names. Access is read-only, and no user data, credential or session material is reachable this way. Such a deployment is rare. The ordinary packaging, a web archive with wicket-core in WEB-INF/lib, puts the framework and the application in one class loader, so the check finds the class file and the template is refused; those deployments are not affected. The exposure is confined to deployments that give wicket-core a class loader which cannot see the application's component classes: wicket-core placed in a servlet container's shared library directory, in an enterprise archive library directory with the application in the web archive, as an application server global module, or as an OSGi bundle, where wicket-core's bundle cannot resolve a class held by an application bundle. Markup shipped by Wicket's own modules, and by any other code sharing a class loader with wicket-core, remains protected. An attacker has to name a component class, and Wicket writes fully qualified class names into the URL of every package resource it renders. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.3d