Base de CVEs

NLTK before 3.10.0 (affected versions <=3.9.4) contains an unsafe pickle deserialization vulnerability in the TransitionParser.parse() method (nltk/parse/transitionparser.py). The method calls pickle_load() with the default restricted=False, routing deserialization through WarningUnpickler, which does not override find_class() and therefore permits arbitrary class resolution. When an application loads an attacker-crafted model file, embedded pickle gadget chains execute arbitrary Python code with the privileges of the user running the application. NLTK provides a RestrictedUnpickler for safe deserialization, but it is not used by production code paths. Fixed in 3.10.0.

GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.

Versões do plugin Grav Login anteriores à 1.0.16 não validam o nível de privilégio da conta-alvo no manipulador de desbloqueio onApiUserListRowAction. Um atacante com a permissão api.users.write pode limpar os contadores de bloqueio de login de contas admin.super, removendo a proteção contra força bruta das contas de maior privilégio sem possuir permissões equivalentes.

O Adminer anterior à 5.4.3 não sanitiza o campo server antes de construir uma string DSN para PDO, permitindo que atacantes não autenticados injetem parâmetros ODBC por meio de ponto e vírgula. Atacantes podem injetar os parâmetros TraceFile e TraceOn para gravar código PHP no diretório raiz web, alcançando execução remota de código quando o arquivo de trace é acessado.

Unauthenticated Privilege Escalation in TranslatePress <= 3.3.2 versions.

Unauthenticated PHP Object Injection in The Events Calendar <= 6.17.2 versions.

Unauthenticated PHP Object Injection in WP Project Manager <= 4.0.6 versions.

CakePHP Authentication is an authentication plugin for CakePHP that can also be used in PSR-7 based applications. Versions before 2.11.2, from 3.0.0 through 3.3.6, and from 4.0.0 through 4.2.0 allow authentication bypass and potential CPU or memory exhaustion when CookieAuthenticator uses unencrypted, forgeable legacy tokens. This issue is fixed in versions 2.11.2, 3.3.7, and 4.2.1.

Injeção de Objeto PHP por Subscriber no ACPT (Pro) - Custom Post Types Plugin for WordPress, nas versões <= 2.0.63.

Upload arbitrário de arquivo por usuário com perfil Subscriber no UltimateAI nas versões ≤ 3.1.0.

Injeção de SQL não autenticada no Boost nas versões <= 2.0.4.

Injeção de SQL não autenticada no WooBeWoo Product Filter Pro nas versões <= 3.1.8.

CakePHP is a rapid development framework for PHP. Prior to versions 5.1.10, 5.2.15, and 5.3.7 on their respective release lines, FunctionsBuilder::jsonValue() with PostgresDriver is vulnerable to SQL injection when user-controlled data is supplied to the jsonPath parameter. This issue is fixed in versions 5.1.10, 5.2.15, and 5.3.7.

An issue in libtiff 85f2ac8e0b01cb7db2bbecf4a3b891bdbef67938 allows an attacker to execute arbitrary code via the process_command_opts() function in tools/tiffcrop.c

RansomLook exposed complete API keys in the HTML source of the authenticated /admin/apikeys administration page. Although the interface displayed only a shortened representation of each key, the full token was embedded in hidden form fields used by the enable/disable, private-access, and delete actions. As a result, API credentials could be recovered by inspecting the page source or DOM. The credentials could also be unintentionally exposed through components that retain or inspect HTTP response bodies, such as debugging proxies, browser caches, monitoring systems, or other intermediaries. An attacker obtaining one of these tokens could subsequently authenticate using the privileges assigned to that key, including access to private data where the key was granted such permissions. The patch removes API keys from subsequent page rendering and replaces them with SHA-256-derived opaque handles. Administrative actions submit only these handles, which are resolved back to the corresponding token on the server. The full API key is therefore disclosed only once, when it is initially created.

Combodo iTop is a web-based IT service management tool. Prior to 3.2.3, unauthenticated users could delete the .readonly file on iTop instances, leading to code execution. This file, created during the setup process, prevents users from performing write actions. This issue has been fixed in version 3.2.3.

O OAuth2 Proxy considera um cabeçalho X-Forwarded-Uri enviado pelo cliente ao decidir se uma requisição pode ignorar a autenticação, porque a proteção adicionada para o CVE-2026-40575 não tem efeito na configuração padrão de proxy reverso. GetRequestURI em pkg/requests/util/util.go prefere esse cabeçalho ao URI real da requisição sempre que CanTrustForwardedHeaders retorna verdadeiro, e isAllowedPath em oauthproxy.go compara o caminho resultante com a lista de permissões skip_auth_routes e skip_auth_regex. CanTrustForwardedHeaders em pkg/apis/middleware/scope.go concede essa confiança quando o endereço do chamador está no conjunto de proxies confiáveis, e buildTrustedProxyNetSet recorre a defaultTrustedProxyIPs, que é 0.0.0.0/0 e ::/0, sempre que o modo de proxy reverso está habilitado sem trusted_proxy_ip configurado. Por isso, todo cliente é tratado como proxy confiável. Um atacante não autenticado pode solicitar um caminho upstream protegido definindo X-Forwarded-Uri com um valor que corresponda a uma rota permitida, de modo que a decisão de pular a autenticação é tomada com base no valor forjado, enquanto o upstream recebe o caminho protegido inalterado.

Vários modelos DrayTek VigorSwitch contêm vulnerabilidades de operação não autorizada em múltiplas funções de syslog. A vulnerabilidade é causada pela ausência de verificações de autorização. Um atacante remoto pode acionar essas vulnerabilidades por meio de requisições especialmente elaboradas para modificar a configuração, reiniciar serviços, salvar a configuração de inicialização ou limpar logs.

Vários modelos DrayTek VigorSwitch contêm uma vulnerabilidade de injeção de comandos pré-autenticação na interface setget.cgi. A vulnerabilidade é causada por filtragem insuficiente do campo pass antes da execução de comandos. Um invasor remoto pode acionar essa vulnerabilidade por meio de entrada criada especialmente para executar comandos arbitrários com privilégios de root.

Vários modelos de pontos de acesso DrayTek VigorAP contêm uma vulnerabilidade de injeção de comandos no componente dray_apm. A vulnerabilidade é causada por validação insuficiente do conteúdo de mensagens UDP após START_SPEED_TEST, antes da execução de comandos. Um atacante remoto pode acionar a vulnerabilidade por meio de uma mensagem especialmente elaborada para executar comandos arbitrários com privilégios de root.

Improper input validation vulnerability in Apache Camel Undertow component. This issue affects Apache Camel: from 4.11.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. UndertowEndpoint defaulted its headerFilterStrategy field to the base HttpHeaderFilterStrategy and pushed that instance into the UndertowHttpBinding it creates lazily, overwriting the UndertowHeaderFilterStrategy that DefaultUndertowHttpBinding installs in its own constructor. Unless a deployment supplied a custom binding or an explicit headerFilterStrategy, the undertow-specific filtering therefore never executed on endpoint-configured routes: the strategy object was constructed and immediately replaced before it could be consulted. The consequence is that the legacy websocket. Exchange-header prefix was not filtered at the undertow transport boundary in either direction, so an undertow HTTP consumer mapped inbound wire headers of that form onto the Exchange, where an undertow WebSocket producer reads them as dispatch directives and can be made to deliver to a peer other than the one the route selected; and header names that undertow itself does not accept were mapped onto the Exchange rather than being skipped. Rest DSL consumers were never affected, because UndertowComponent assigns UndertowRestHeaderFilterStrategy explicitly, which extends the undertow strategy. This is not a regression of CVE-2025-30177: the base HttpHeaderFilterStrategy configures the inbound Camel-prefix filter itself, so the protection introduced by that advisory continued to work through the base class and was never lost. What the change did was leave the undertow strategy orphaned on the endpoint path, with the effect that two subsequent corrections written into it - one skipping header names undertow rejects, one filtering the legacy websocket. prefix in both directions - were applied to a class the endpoint no longer used and never took effect in the releases that shipped them. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, configure the strategy explicitly rather than relying on the default, for example by binding an UndertowHeaderFilterStrategy in the registry and referencing it on the endpoint as undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, and additionally strip the dispatch headers at the trust boundary with removeHeaders(“websocket.*”). Note a residual limitation that upgrading does not remove: the undertow component deliberately keeps the websocket. values as part of its externally visible API contract, and UndertowProducer reads them with in.getHeader, which does not consult a HeaderFilterStrategy at all. The restored filtering is therefore defence in depth at the undertow transport boundary only. A route that carries an untrusted message from a non-undertow consumer into an undertow producer is not protected by this fix and must strip those headers itself.

rConfig Core 8.0.0 before 8.2.10 contains an authentication bypass vulnerability that allows unauthenticated attackers to self-register accounts with full Administrator privileges due to a duplicate bare Auth::routes() call in routes/web.php that re-enables the POST /register route after it was explicitly disabled. Attackers can register a new account that is immediately authenticated with Admin-level access because the registration controller does not assign a role and the users.role column defaults to Admin, enabling access to stored device credentials, user data, and API token issuance.

Vulnerabilidade de validação imprópria de entrada no componente Apache Camel Atmosphere Websocket. Este problema afeta o Apache Camel: de 4.0.0 antes de 4.14.9, de 4.15.0 antes de 4.18.4, de 4.19.0 antes de 4.22.0. O produtor camel-atmosphere-websocket seleciona para quais pares WebSocket conectados uma mensagem é entregue por meio de cabeçalhos do Exchange, e os valores em string desses cabeçalhos estavam fora do namespace Camel: websocket.connectionKey e websocket.connectionKey.list, além de websocket.sendToAll, websocket.eventType e websocket.errorType. WebsocketEndpoint estende ServletEndpoint e, por isso, herda HttpHeaderFilterStrategy, que filtra apenas os prefixos Camel e camel; os nomes com ponto ficaram, portanto, fora do namespace filtrado e foram admitidos em ambas as direções por todo consumidor da família HTTP. Em uma rota que conecta um consumidor HTTP a um produtor atmosphere-websocket, um remetente externo poderia fornecer o cabeçalho de lista e assumir a decisão de despacho do produtor. WebsocketProducer.process testa o cabeçalho de lista antes do cabeçalho de chave única, portanto um valor injetado descartava o destinatário que a rota havia selecionado: uma notificação destinada a um cliente conectado poderia ser suprimida ou entregue a outro cliente cuja chave de conexão o remetente conhece. O cabeçalho não precisa ser um parâmetro de consulta nem ser fornecido literalmente como lista. O binding HTTP do Camel promove um nome de cabeçalho repetido, e um valor entre colchetes, para List ao mapear para o Exchange, de modo que um cabeçalho HTTP de entrada comum basta para alcançar o ramo com valor de lista. Isto é distinto de CVE-2026-55993, que trata do caminho de parâmetros de consulta no lado do consumidor do mesmo componente. O comportamento remonta à introdução dessas constantes, lançadas pela primeira vez na versão 2.17.0, e permaneceu inalterado até esta correção. Os usuários são recomendados a atualizar para a versão 4.22.0, que corrige o problema. Se os usuários estiverem na linha de releases LTS 4.14.x, sugere-se atualizar para 4.14.9. Se estiverem na linha de releases 4.18.x, sugere-se atualizar para 4.18.4. Para implantações que não podem atualizar imediatamente, remova os cabeçalhos de despacho na fronteira de confiança, antes do produtor, por exemplo com removeHeaders(“websocket.*”) posicionado entre o consumidor HTTP e o produtor atmosphere-websocket. Observe que a correção renomeia os valores de string dos cabeçalhos para o namespace Camel, o que é uma mudança incompatível para rotas que os definem por string literal; rotas que referenciam os campos de WebsocketConstants simbolicamente não são afetadas, e a mudança está documentada nos guias de atualização. Como defesa em profundidade, não conecte diretamente um consumidor HTTP não confiável a um produtor WebSocket cujo despacho seja guiado por cabeçalhos sem remover antes o namespace de despacho.

Relative path traversal vulnerability in Apache Camel Azure Storage Blob component. This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-azure-storage-blob component can download an Azure Storage blob to the local filesystem through its downloadBlobToFile operation, writing into the directory named by the fileDir endpoint option, which is documented as usable from both the producer and the consumer. BlobOperations.downloadBlobToFile built the local target by joining fileDir with the remote blob name exactly as the Azure SDK reported it (new File(fileDir, client.getBlobName())) and passed the result straight to the SDK download call, with no lexical normalization and no check that the resolved location stayed inside fileDir. The blob name is not route-controlled data: the consumer enumerates the container in BlobConsumer.createBatchExchangesFromContainer, which lists blobs and creates one exchange per entry from BlobItem.getName() verbatim, applying no name filtering by default. A blob name containing parent-directory segments therefore resolved to a location outside the configured fileDir, letting anyone able to influence the names present in the consumed container cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. Azure Storage blob containers use a flat namespace in which the blob name is an opaque key, so a name carrying such segments is stored and listed as given. The fileDir option is an ordinary common-group configuration parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp and camel-azure-files - already constrained their local downloads to the configured directory using a path-segment boundary check; the camel-azure-storage-blob download path was not covered by that work. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, constrain the names the consumer will act on using the regex endpoint option, which is applied to each listed blob name as a full-string match, so that only simple single-segment names are accepted and any name carrying a path separator or a parent-directory segment is filtered out before an exchange is created; the prefix option can additionally narrow the listing server-side, noting that when both are set regex takes priority and prefix is ignored. Alternatively, avoid the downloadBlobToFile operation on untrusted containers and write the payload from the route under a file name the route itself controls, rather than one taken from the remote listing. As defence in depth, treat the blob names in any externally writable container as untrusted input and do not derive local filesystem paths from them.

Netis NC63 firmware through V3.0.0.3327 contains a stack-based buffer overflow vulnerability that allows unauthenticated remote attackers to overwrite saved stack state by supplying an oversized destHost parameter to the ipFilterList=mod action in netis.cgi. Attackers can exploit widthless sscanf conversions that copy user-supplied input into fixed-size stack buffers before authentication is verified, achieving remote code execution as root due to the Boa web server executing the CGI environment with root privileges.