{"schema_version":"1.0","service":"Publicasta","type":"article","id":890,"slug":"curl_http2_upload_use_after_free_cve_2026_92392_response","title":"CVE-2026-92392 en curl: por qué las cargas HTTP/2 requieren una respuesta a nivel de dependencia","excerpt":"curl 8.23.0 corrige un use-after-free de alta gravedad en cargas HTTP/2. El riesgo práctico depende de cómo se utilicen curl y libcurl, por lo que hay que localizar copias, actualizar rutas y revisar los flujos de carga.","language":"es","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=es","image":{"url":"https://publicasta.com/storage/projects/9/pages/890/2026/10/cf42bf44-8d6a-4849-9fdc-3b7455e89b6c.webp","alt":"Ilustración editorial de ciberseguridad: una carga HTTP/2 llega a un servidor mientras ingenieros siguen un parche de curl y el inventario de dependencias."},"publisher":{"id":9,"slug":"cybersecurity","name":"Ciberseguridad sin pánico","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-10-15T13:39:51+00:00","updated_at":"2026-10-15T13:39:51+00:00","content_markdown":"Una vulnerabilidad de alta gravedad en curl y libcurl cambia la forma habitual de pensar en la seguridad del lado cliente. CVE-2026-92392 se activa durante una carga HTTP/2, pero el actor hostil es el servidor que recibe esa carga. Un servidor malicioso puede enviar una respuesta concreta de reinicio de flujo mientras el cliente transmite datos, dejando a curl con una referencia a un objeto que ya fue liberado. El resultado es corrupción de memoria, y el proyecto curl afirma que se ha demostrado que el fallo puede convertirse en ejecución remota de código cuando coinciden unas condiciones exigentes de compilación, arquitectura, asignador de memoria, temporización y protocolo.\n\n ![Ilustración editorial de ciberseguridad: una carga HTTP/2 llega a un servidor mientras ingenieros siguen un parche de curl y el inventario de dependencias.](https://publicasta.com/storage/projects/9/pages/890/2026/10/cf42bf44-8d6a-4849-9fdc-3b7455e89b6c.webp)\n\n La corrección está en curl y libcurl 8.23.0, publicados el 14 de octubre de 2026. El intervalo afectado va de 8.12.0 a 8.22.0. Ese rango importa porque libcurl suele estar integrado en aplicaciones, componentes del sistema operativo, herramientas de automatización, gestores de paquetes, productos de seguridad y servicios que no anuncian que utilizan curl. Actualizar el binario de línea de comandos en el equipo de un administrador puede dejar intactas las copias más importantes.\n\n Esta es una historia de parcheo, pero no una historia sencilla de «ejecutar la actualización en todas partes». El primer trabajo consiste en descubrir dónde se utiliza curl para cargas mediante HTTP/2, incluso a través de una biblioteca o de una aplicación enlazada estáticamente. El segundo es decidir si resulta práctico reducir temporalmente la capacidad de protocolo mientras la corrección permanente avanza por los paquetes de los proveedores y las ventanas de cambio de producción. El tercero es comprobar si los sistemas que cargan archivos pueden confiar en que solo contactarán con los destinos previstos.\n\n ## Qué afecta realmente CVE-2026-92392\n\n El aviso de curl describe un use-after-free en la ruta de carga HTTP/2. Durante una carga, el servidor puede emitir un `RST_STREAM` de HTTP/2 con el motivo `HTTP_1_1_REQUIRED` o `REFUSED_STREAM`. La conexión puede permanecer activa mientras se detiene la transferencia individual. En la máquina de estados vulnerable, curl limpia después la transferencia y la conexión en un orden que deja una referencia colgante al objeto de transferencia.\n\n Un use-after-free no significa automáticamente que cada ejecución se convierta en ejecución de código. Significa que el software continúa utilizando memoria después de que su propietario la haya liberado. Según qué ocupe esa memoria a continuación, el resultado inmediato puede ser un bloqueo, un estado corrupto, una exposición de información o un fallo de seguridad de memoria más controlado. En este caso, el proyecto curl clasifica el problema como de gravedad Alta y documenta una vía desde el error de memoria hasta la ejecución remota de código.\n\n Las versiones afectadas son curl y libcurl 8.12.0 a 8.22.0, ambas incluidas. Las versiones anteriores a 8.12.0 no están afectadas por este fallo concreto, y la 8.23.0 contiene la corrección. La diferencia entre curl y libcurl es importante desde el punto de vista operativo: la herramienta de línea de comandos es un consumidor, mientras que un número mucho mayor de aplicaciones puede llamar directamente a la biblioteca. Un servidor que nunca ejecuta el binario `curl` puede seguir expuesto mediante una aplicación enlazada contra libcurl.\n\n La vulnerabilidad requiere HTTP/2. Eso no significa que toda transferencia HTTPS sea vulnerable automáticamente, pero sí que los equipos no deben deducir que están a salvo solo porque los usuarios no pasaron explícitamente una opción HTTP/2. curl puede negociar HTTP/2 al conectarse con un servicio HTTPS que lo ofrece y cuando la compilación local incluye el soporte pertinente. Las aplicaciones también pueden seleccionar HTTP/2 de forma explícita mediante opciones de libcurl o marcos de red de más alto nivel.\n\n La operación vulnerable es una carga desde el cliente hacia el servidor. Las descargas ordinarias no son el escenario descrito por el aviso. Esto reduce la exposición, pero no convierte el problema en algo exótico. Agentes de copias de seguridad, publicadores de artefactos, clientes de telemetría, servicios de ingestión documental, sistemas de integración continua, conectores en la nube, herramientas de soporte al cliente, programas de sincronización y API internas envían datos al exterior con frecuencia. Algunos usan curl solo en una pequeña parte de un flujo más amplio, precisamente por lo que un inventario de paquetes puede pasar por alto la exposición práctica.\n\n ## El atacante está en el lado receptor\n\n Muchos manuales defensivos empiezan suponiendo que el servidor peligroso es el que sirve una descarga. CVE-2026-92392 invierte ese modelo mental. El cliente inicia una carga hacia un servidor que considera confiable, y el servidor puede ser el componente que proporciona el comportamiento de protocolo malicioso.\n\n Eso no significa que un atacante pueda explotar cualquier proceso de curl simplemente colocando una página maliciosa en internet. El proceso víctima debe conectarse a un servidor controlado o influido por el atacante, realizar una carga, negociar HTTP/2 y satisfacer las condiciones de implementación necesarias para alcanzar la secuencia de limpieza vulnerable. En un entorno real, esto podría ocurrir mediante un endpoint deliberadamente malicioso, un servicio comprometido, un flujo redirigido, un destino de carga elegido por el usuario o una aplicación que acepta configuración remota. La ruta exacta depende del producto que rodea a curl.\n\n El proyecto curl enumera requisitos inusualmente específicos para convertir el fallo en ejecución de código. El atacante necesita conocer la versión exacta de curl y la disposición de los objetos, detalles de la arquitectura objetivo, un asignador libc y una disposición del heap compatibles, efectos predecibles de nghttp2 y TLS 1.3, y una temporización cuidadosamente controlada entre transferencias paralelas. El exploit publicado también tiene una restricción de comandos breves. Esas condiciones dificultan una explotación fiable, pero no justifican tratar el problema como inofensivo. Muchas cadenas de ataque modernas empiezan con un bloqueo o una corrupción parcial de memoria y mejoran a medida que se conocen detalles del objetivo.\n\n El registro público distingue actualmente entre explotabilidad y explotación conocida. El aviso documenta una prueba de concepto y una vía hacia la ejecución de código bajo condiciones precisas. La entrada del NVD no proporciona una evaluación CVSS propia ni afirma que la vulnerabilidad esté siendo explotada activamente. Una prueba de concepto pública sigue siendo una señal relevante para los defensores, especialmente donde curl está integrado en servicios de larga duración o se actualiza con lentitud. No demuestra que toda instalación vulnerable haya sido comprometida.\n\n ## Por qué la versión 8.23.0 requiere una gestión cuidadosa\n\n La corrección llegó en una versión coordinada de curl que también solucionó otros 23 problemas de seguridad publicados, la mayoría calificados como de gravedad Baja por el proyecto. CVE-2026-92392 es el único problema de gravedad Alta de la versión. Esa agrupación crea dos riesgos operativos opuestos. Algunos equipos pueden ver el gran número de avisos y paralizarse porque la actualización parece complicada. Otros pueden actualizar un paquete visible de línea de comandos y asumir que todo el grafo de dependencias está cubierto.\n\n La respuesta correcta es separar la urgencia de la uniformidad. Lo urgente es identificar las compilaciones vulnerables que realizan cargas y mover esos sistemas a un paquete corregido del proveedor o a curl y libcurl 8.23.0. La vía de implementación puede cambiar según el sistema operativo, la imagen base del contenedor, el entorno de ejecución del lenguaje, el dispositivo o la aplicación comercial. Un paquete de libcurl mantenido por una distribución puede incorporar la corrección sin cambiar la versión ascendente mostrada de la forma que espera una comprobación simplista. Por eso los equipos de seguridad deben confirmar el aviso del proveedor y el registro de cambios del paquete, en lugar de confiar en una sola comparación de cadenas.\n\n La versión también modifica aspectos que no son de seguridad. El proyecto eliminó el soporte para SMB y SMBS e introdujo otros cambios de comportamiento y correcciones de errores. Eso no hace insegura la actualización, pero sí refuerza la necesidad de probar aplicaciones que dependan de protocolos menos comunes, flujos de autenticación poco habituales, backends TLS personalizados o un manejo estricto de archivos. La corrección de seguridad no debería retrasarse hasta contar con un conjunto de pruebas universal perfecto; aun así, un despliegue gradual puede evitar que la propia mitigación interrumpa un servicio de cargas crítico.\n\n Curl mantiene información de versiones separada para las versiones estándar y sus ramas Rock-solid. Las organizaciones que consumen una rama de soporte prolongado deben comprobar si la versión adecuada de esa rama es 8.14.3, 8.16.2 o 8.20.2, en vez de sustituirla a ciegas por la rama estándar más reciente. La pregunta decisiva no es «¿qué número mostraba la página de descargas del binario de línea de comandos?», sino «¿qué paquete compatible contiene la corrección para CVE-2026-92392 y cómo podemos demostrar que está desplegado?».\n\n ## Un inventario práctico para esta vulnerabilidad\n\n Empieza por las instalaciones obvias, pero no te detengas ahí. Busca el ejecutable `curl` en endpoints e imágenes de servidor, consulta los gestores de paquetes del sistema operativo, inspecciona las capas de los contenedores, revisa las listas de materiales de software y examina los manifiestos de compilación en busca de libcurl. Los nombres de los paquetes varían: un host puede mostrar `curl`, `libcurl`, un paquete de desarrollo o un paquete de ejecución específico del proveedor. El enlazado estático puede hacer que la biblioteca desaparezca de la base de datos ordinaria de paquetes del host, por lo que los manifiestos de lanzamiento de la aplicación y los SBOM son pruebas valiosas.\n\n Después añade el comportamiento al inventario. Los registros prioritarios son los procesos que cumplen todo lo siguiente:\n\n - ejecutan una compilación vulnerable de curl o libcurl;\n- cargan archivos o cuerpos de solicitud a un servicio remoto;\n- permiten negociar HTTP/2 o habilitan HTTP/2 explícitamente; y\n- manejan datos o credenciales cuya pérdida tendría consecuencias.\n\n Una biblioteca vulnerable utilizada solo para analizar metadatos locales no debería recibir el mismo tratamiento inmediato que un servicio de automatización expuesto que carga credenciales, artefactos de compilación, documentos de clientes o copias de seguridad. La clasificación del riesgo también debe tener en cuenta quién controla el destino. Una lista permitida fija de endpoints de un proveedor representa una exposición distinta a la de una herramienta que acepta una URL arbitraria desde un usuario, un parámetro de trabajo, un webhook o un archivo de configuración remota.\n\n En productos enlazados estáticamente u opacos, pide al proveedor tres respuestas concretas: si el producto incluye curl o libcurl dentro del rango afectado, si puede realizar cargas HTTP/2 y qué compilación contiene la corrección. Conserva la respuesta junto al registro del activo. «El producto usa HTTPS» no es una evaluación suficiente, y «el producto no muestra curl en su interfaz» no responde a la pregunta sobre sus dependencias integradas.\n\n Los entornos de contenedores requieren una comprobación adicional. Actualizar el host no actualiza una imagen antigua, y reconstruir una imagen de aplicación no sustituye necesariamente una biblioteca curl copiada en la etapa final. Analiza tanto la imagen que está ejecutándose como la que se promoverá después. Si el orquestador conserva réplicas antiguas durante un despliegue gradual, confirma que todas las réplicas activas han salido del rango afectado antes de cerrar el incidente o el ticket de vulnerabilidad.\n\n ## Mitigaciones temporales mientras llegan los parches\n\n El aviso de curl enumera evitar HTTP/2 como alternativa cuando la actualización o el parcheo no son posibles de inmediato. Es una mitigación, no un sustituto de la corrección. En un flujo de línea de comandos, un operador puede forzar HTTP/1.1 para una transferencia bien delimitada. En una aplicación, el ajuste equivalente puede ser una opción de la biblioteca, una política del proxy, una regla del service mesh o una configuración del proveedor. El control debe probarse: desactivar HTTP/2 en un envoltorio no ayuda si la aplicación subyacente abre otra conexión por un camino de código distinto.\n\n Una restricción temporal de protocolo también puede tener efectos secundarios. Algunos servicios requieren HTTP/2, utilizan multiplexación de conexiones para obtener rendimiento o aplican un comportamiento diferente de autenticación y tiempos de espera según el protocolo. Documenta la excepción, identifica al responsable y fija una fecha de caducidad. Una mitigación que permanece indefinidamente porque nadie sabe si sigue activa se convierte en otro problema de inventario.\n\n Siempre que sea posible, limita los destinos de carga durante el periodo intermedio. Aplica listas permitidas de salida para los trabajos automatizados, rechaza destinos proporcionados por usuarios salvo que el flujo los necesite explícitamente y verifica las redirecciones en lugar de seguir en silencio una cadena hasta un host inesperado. Estas medidas reducen la posibilidad de que un cliente vulnerable alcance un servidor receptor malicioso, pero no sustituyen el parche: un destino legítimo puede verse comprometido y una lista permitida amplia todavía puede incluir infraestructura controlada por un atacante.\n\n No respondas desactivando la verificación de certificados ni debilitando TLS. Las condiciones del exploit incluyen un servidor que supera las comprobaciones de certificados del cliente, un recordatorio de que la autenticación ordinaria del transporte no es una defensa completa contra un endpoint comprometido o operado de forma maliciosa. Eliminar la verificación de certificados ampliaría la superficie de ataque sin resolver el fallo de seguridad de memoria.\n\n ## Qué examinar si un cliente vulnerable estuvo expuesto\n\n Una versión vulnerable no demuestra que haya habido compromiso, y un bloqueo no demuestra que se haya explotado la vulnerabilidad. Aun así, un cliente de carga expuesto merece una revisión proporcional. Identifica los destinos contactados durante el periodo relevante, los archivos o cuerpos de solicitud enviados, la compilación exacta de curl o libcurl y si se negoció HTTP/2. Los registros de la aplicación, del proxy, la telemetría TLS y los registros de procesos del endpoint pueden responder a estas preguntas aunque curl solo registre un error genérico de transferencia.\n\n Busca terminaciones anómalas, reintentos repetidos contra un endpoint inusual, cambios en los procesos hijos lanzados por el cargador, archivos inesperados y conexiones salientes que comenzaran justo después de una transferencia fallida. Son señales de triaje, no indicadores exclusivos de CVE-2026-92392. Un fallo normal de carga puede producir reintentos y un bloqueo puede provocar un reinicio, por lo que la interpretación debe relacionarse con el comportamiento esperado del host.\n\n Si el proceso tenía acceso a credenciales, tokens, claves de firma o archivos locales sensibles, evalúa ese acceso por separado. La vulnerabilidad publicada es un problema de seguridad de memoria del cliente; no se describe como un fallo directo de divulgación de credenciales. Sin embargo, una ejecución de código exitosa en un cargador podría exponer los privilegios y datos disponibles para ese proceso. Rota los secretos cuando la investigación no pueda demostrar que el proceso se mantuvo dentro de sus límites esperados y conserva los registros pertinentes antes de que la retención rutinaria los elimine.\n\n En sistemas de alto valor, compara la compilación vulnerable con la corregida y conserva pruebas de la actualización. Captura la suma de comprobación del paquete o el digest de la imagen, la versión del proceso en ejecución y la marca temporal del despliegue. Si el proveedor del producto proporciona un hotfix en lugar de una versión ascendente, registra el boletín del proveedor y el identificador de compilación del paquete. Esta evidencia es más útil que un comentario de ticket que diga «curl parcheado», sobre todo cuando existen varias copias de la biblioteca en el mismo host.\n\n ## Qué deben cambiar los desarrolladores\n\n Los desarrolladores deben tratar libcurl como parte del límite de seguridad de la aplicación, no como una utilidad intercambiable escondida bajo la lógica de negocio. Fijar una versión en un archivo de compilación no basta si la imagen de ejecución proporciona una biblioteca compartida distinta, si la imagen base está obsoleta o si un gestor de paquetes resuelve una versión vulnerable durante una reconstrucción. Haz visible la dependencia en el SBOM y establece una ruta de actualización repetible.\n\n Revisa el código de carga para comprobar el control del destino, el comportamiento de las redirecciones, la lógica de reintentos y la selección del protocolo. Un servicio que solo carga a un endpoint fijo tiene un modelo de amenaza distinto al de otro que acepta URL arbitrarias. Una biblioteca de reintentos puede realizar una segunda conexión con opciones distintas de las de la primera. Un proxy puede negociar HTTP/2 aunque la aplicación no lo haya indicado explícitamente. La revisión de seguridad debe seguir el camino real de conexión, no el archivo de configuración más cómodo.\n\n Limita los privilegios de los trabajadores de carga. Ejecútalos con el mínimo acceso de sistema de archivos, red y credenciales que necesite el trabajo. Utiliza identidades separadas para leer un archivo local y publicarlo, y evita conceder a un trabajador de transferencias genérico acceso a credenciales de administrador de la nube, claves de firma o el socket del contenedor del host. El mínimo privilegio no elimina la vulnerabilidad, pero puede convertir un evento de ejecución de código en un incidente contenido del servicio, en lugar de una intrusión más amplia del host.\n\n Añade pruebas de rutas negativas para transferencias HTTP/2 interrumpidas, reinicios del servidor, reintentos y limpieza. El objetivo no es reproducir el exploit en producción ni crear capacidad ofensiva. Es comprobar que la aplicación gestiona de forma segura una transferencia fallida, que la dependencia corregida se carga realmente y que el comportamiento de reinicio y reintento no crea una segunda vía que evite la actualización.\n\n ## Qué deben comunicar los equipos de operaciones\n\n El aviso interno más útil es preciso: CVE-2026-92392 afecta a curl y libcurl 8.12.0 a 8.22.0; el escenario vulnerable implica una carga HTTP/2; la versión ascendente corregida es la 8.23.0; y las copias integradas de la biblioteca también cuentan. Evita decir a todos los empleados que actualicen un navegador o que dejen de usar internet. La mayoría no opera los flujos de carga afectados, y las advertencias indiscriminadas hacen que la próxima alerta grave sea más difícil de escuchar.\n\n Pide a los responsables de los servicios que informen si sus sistemas cargan datos, qué destinos contactan, si HTTP/2 está habilitado y qué paquete o imagen proporciona curl. Ofréceles una mitigación temporal que pueda verificarse y un responsable de la actualización permanente. Así, una alerta amplia sobre dependencias se convierte en un conjunto de preguntas contestables.\n\n La divulgación del proyecto curl también ofrece una lección más amplia. Un componente maduro y sometido a un escrutinio intenso todavía puede contener un fallo grave de seguridad de memoria. Ese hecho no debería desencadenar un ciclo de pánico en el que los equipos sustituyan software fiable por alternativas sin verificar. Debería impulsar una visibilidad disciplinada de las dependencias, una propagación más rápida de los parches, privilegios de proceso más seguros y pruebas más claras sobre la forma en que se negocian los protocolos de red.\n\n ## Conclusión\n\n CVE-2026-92392 merece prioridad porque combina una presencia amplia como dependencia con un disparador del lado servidor durante las cargas del cliente. No es una toma de control remota universal de toda instalación de curl, y las condiciones de explotación publicadas son exigentes. La ausencia de una señal actual de explotación conocida no convierte en cómoda una excepción prolongada para un servicio de cargas sin parchear.\n\n Localiza todas las copias de curl y libcurl, identifica cuáles cargan datos mediante HTTP/2, actualiza las compilaciones vulnerables a una versión corregida compatible con el proveedor y utiliza HTTP/1.1 o restricciones de destino únicamente como controles temporales. Después conserva pruebas de que el proceso en ejecución —no solo el archivo de compilación o la imagen base— contiene la corrección. Esa es la respuesta que exige esta vulnerabilidad: específica, consciente de las dependencias y lo bastante serena como para encontrar las copias que nadie recordaba que estaban allí.\n\n ## Fuentes\n\n La información técnica y contextual se basa en el aviso de seguridad del proyecto curl sobre CVE-2026-92392, la ficha correspondiente del National Vulnerability Database, la explicación publicada por Daniel Stenberg, el análisis de The Hacker News, el registro de cambios de curl 8.23.0 y la tabla de versiones del proyecto curl.","available_translations":[{"language":"ar","title":"CVE-2026-92392 في curl: لماذا تحتاج عمليات الرفع عبر HTTP/2 إلى استجابة على مستوى التبعية","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=ar"},{"language":"de","title":"CVE-2026-92392 in curl: Warum HTTP/2-Uploads eine Reaktion auf Abhängigkeitsebene erfordern","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=de","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=de","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=de"},{"language":"en","title":"CVE-2026-92392 in curl: Why HTTP/2 Uploads Need a Dependency-Level Patch Response","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=en","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=en","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=en"},{"language":"es","title":"CVE-2026-92392 en curl: por qué las cargas HTTP/2 requieren una respuesta a nivel de dependencia","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=es","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=es","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=es"},{"language":"fr","title":"CVE-2026-92392 dans curl : pourquoi les téléversements HTTP/2 exigent une réponse au niveau des dépendances","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=fr"},{"language":"pl","title":"CVE-2026-92392 w curl: dlaczego przesyłanie przez HTTP/2 wymaga reakcji na poziomie zależności","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=pl"},{"language":"ru","title":"CVE-2026-92392 в curl: почему для загрузок HTTP/2 нужен патч на уровне зависимости","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=ru"},{"language":"zh","title":"curl 中的 CVE-2026-92392：为何 HTTP/2 上传需要依赖级别的补丁响应","html_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=es","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=es","html":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=es","canonical":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response?lang=es","markdown":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.md?lang=es","json":"https://publicasta.com/cybersecurity/curl_http2_upload_use_after_free_cve_2026_92392_response.json?lang=es","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}