Base de CVEs

Other issue in the DevTools component. This vulnerability was fixed in Thunderbird 157 and Firefox 157.

Sandbox escape due to use-after-free in the Preferences: Backend component. This vulnerability was fixed in Thunderbird 157 and Firefox 157.

Sandbox escape due to use-after-free in the Disability Access APIs component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 153.4, and Firefox 157.

Sandbox escape due to incorrect boundary conditions in the Internationalization component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, and Firefox ESR 140.17.

Invalid pointer in the JavaScript: WebAssembly component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, and Firefox ESR 140.17.

Sandbox escape in the XUL component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 153.4, and Firefox 157.

Sandbox escape due to use-after-free in the Graphics component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.

Sandbox escape due to incorrect boundary conditions in the Graphics: WebRender component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.

Sandbox escape due to use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.

Sandbox escape in the Graphics component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.

Sandbox escape due to use-after-free in the DOM: Content Processes component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.

Sandbox escape in the Security: Process Sandboxing component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 153.4, and Firefox 157.

Sandbox escape in the DOM: Navigation component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.

Condições de limite incorretas no componente Graphics: WebGPU. Esta vulnerabilidade foi corrigida no Thunderbird 157 e no Firefox 157.

Escape de sandbox devido a use-after-free no componente DOM: Content Processes. Esta vulnerabilidade foi corrigida no Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42 e Firefox ESR 140.17.

Google Merchant Center Feed (gmfeed) module for PrestaShop is vulnerable to unauthenticated arbitrary file write in the feed.php endpoint. An unauthenticated attacker can send a crafted request that controls the output file name, path, extension, and content through request parameters. Due to the lack of authentication and input validation, the request is processed successfully, allowing an attacker to write and execute arbitrary PHP code, resulting in remote code execution (RCE). This issue was fixed in version 2.3.9.

Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, Versions prior to 5.36, contains a Download of Code Without Integrity Check vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Code execution, Information disclosure, Information tampering, and Protection mechanism bypass.

A directory traversal vulnerability in the file upload functionality of Hitachi Energy RTU500 end-of-life versions allows an unauthenticated attacker to write or overwrite arbitrary files on the device file system. Depending on the files affected, successful exploitation could result in unauthorized modification of device data or disruption of the device’s intended operation.

An authentication bypass vulnerability in the firmware update endpoint of Hitachi Energy RTU500 end-of-life versions allows an unauthenticated attacker to upload arbitrary firmware through a crafted POST request. Successful exploitation could allow the attacker to modify device functionality or compromise the integrity or availability of the device.

Das U-Boot with CONFIG_IP_DEFRAG=y parameter fails to clear IP reassembly state after delivering a complete datagram. An attacker who can deliver fragmented IP traffic can execute arbitrary code by sending duplicated last-fragment IP packets. This issue was fixed in commit b1aec609bb5e0d08c25c888c91935287ab4ee5fa in version 2026.07.

Unrestricted Upload of File with Dangerous Type in the /WebAgenda/download/uploadFile.jsp API endpoint of Flowring Agentflow 4.0 version before 2023/03/24 allows remote authenticated users to execute arbitrary system commands via a malicious file.

SQL Injection in the /WebAgenda/SMBAjaxConfigProcess.do API endpoint of Flowring Agentflow 4.0 version before 2025/08/08 allows remote attackers to execute arbitrary SQL commands via the id parameter.

SQL Injection in the /WebAgenda/SMBAjaxAutoComplete.do API endpoint of Flowring Agentflow 4.0 version before 2025/08/08 allows remote attackers to execute arbitrary SQL commands via the words parameter.

O escopo de comandos de shell jdbc não incluía o arquivo org.apache.karaf.command.acl.jdbc.cfg. O guarda de comandos do Karaf (SecuredSessionFactoryImpl) trata um comando sem regra ACL correspondente como permitido, de modo que qualquer sessão de shell autenticada (inclusive uma que tenha apenas o papel viewer) podia executar todos os comandos jdbc:*. O jdbc:ds-create armazena uma URL JDBC totalmente controlada pelo atacante em uma Configuration de fábrica pax-jdbc-config sem nenhuma validação. O pax-jdbc-config transforma isso reativamente em um DataSource ativo. Vários drivers JDBC executam código ou SQL no momento da conexão com base em parâmetros da URL (por exemplo, H2 INIT=RUNSCRIPT), de modo que um usuário de shell de nível viewer poderia chegar à execução arbitrária de código, contornando a barreira de papel admin que já protege o shell:exec. Trata-se de uma cadeia de escalonamento de privilégio para RCE, e não apenas de uma «má configuração do administrador». O mesmo se aplica aos comandos de shell jms:*.

org.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, properties), que sustenta o MBean "config" e os comandos de shell config:*, deriva o arquivo para o qual grava uma configuração a partir de entrada fornecida pelo chamador sem verificar se o resultado permanece dentro de ${karaf.etc}: * se o mapa de propriedades enviado contiver uma entrada felix.fileinstall.filename, esse valor é convertido diretamente em um File (getCfgFileFromProperty), podendo apontar para qualquer caminho absoluto que o processo Karaf consiga gravar; * caso contrário, o PID de configuração é concatenado literalmente ao nome do arquivo de destino (generateConfigFilename(): new File(karaf.etc, pid + ".cfg")), de modo que um PID contendo segmentos ".." resolve para fora de ${karaf.etc}. createFactoryConfiguration() tem o mesmo problema por meio do PID/alias da fábrica. Ambos os caminhos de código são alcançáveis por qualquer chamador que possua o papel "manager" sob a ACL padrão de comandos/JMX do Karaf (org.apache.karaf.command.acl.conf.cfg: "update = manager"). Esse usuário pode, portanto, gravar conteúdo controlado pelo atacante em qualquer arquivo que o processo Karaf consiga escrever, incluindo arquivos que a mesma ACL reserva ao papel "admin" (etc/users.properties, etc/*.acl.*.cfg, etc/org.apache.karaf.management.cfg e similares), permitindo que um usuário com papel manager conceda a si mesmo o papel admin ou assuma o controle do contêiner. ConfigMBeanImpl.install() e o comando de shell config:install já protegiam o risco equivalente em seu próprio caminho de código com uma verificação de string finalname.contains(".."), mas essa verificação não impede caminhos absolutos nem escapes baseados em links simbólicos, e nunca foi aplicada a ConfigRepositoryImpl.update() / createFactoryConfiguration().