Cuando la responsabilidad es unilateral: el dilema de la divulgaci贸n coordinada
Una reflexi贸n sobre el modelo actual de seguridad, sus asimetr铆as y sus consecuencias
Imagina la siguiente situaci贸n:
Has pasado semanas, quiz谩s meses, investigando un comportamiento extra帽o en un sistema ampliamente utilizado. Has reproducido el problema en diferentes dispositivos. Has capturado logs, stacktraces, m茅tricas de sistema. Has documentado cada paso con precisi贸n. Has preparado un informe que cualquier ingeniero podr铆a seguir para verificar el problema por s铆 mismo.
Env铆as el reporte al fabricante. Esperas. Recibes una respuesta autom谩tica. Semanas despu茅s, alguien te pide m谩s informaci贸n. La proporcionas. Vuelves a esperar.
Finalmente, recibes una respuesta:
“Hemos revisado tu informe y determinado que no cumple con los criterios para ser considerado un bug de seguridad.”
“Este problema pertenece a otro equipo.”
“Est谩 fuera del alcance de nuestro programa de recompensas.”
“Por favor, utiliza el feedback in-product para reportarlo.”
El problema sigue existiendo. Los usuarios siguen expuestos. Pero la responsabilidad ha quedado diluida en un laberinto de equipos, programas y criterios.
Esta historia es m谩s com煤n de lo que muchos creen. Y revela una asimetr铆a estructural en el modelo de divulgaci贸n coordinada que merece un an谩lisis profundo.
Este art铆culo no trata sobre una vulnerabilidad concreta. Trata sobre el sistema que la gestiona o, m谩s precisamente, sobre el sistema que a menudo no la gestiona.
1. El contrato impl铆cito de la divulgaci贸n responsable
La divulgaci贸n responsable, tambi茅n llamada coordinada, se ha establecido como el est谩ndar 茅tico en la seguridad inform谩tica. Su premisa es sencilla y, en apariencia, incuestionable:
“Si conocemos un problema que puede afectar a otros, debemos dar al fabricante la oportunidad de solucionarlo antes de hacerlo p煤blico.”
Esta l贸gica protege a los usuarios. Permite que las empresas corrijan vulnerabilidades sin exponer a sus clientes a ataques mientras el parche est谩 en desarrollo. Es un modelo que, en teor铆a, beneficia a todas las partes.
En la pr谩ctica, el investigador acepta un conjunto de obligaciones que incluyen:
- Reproducir el problema de forma fiable y documentada.
- Proporcionar evidencia t茅cnica suficiente (logs, trazas, c贸digo, pasos).
- Evitar divulgar prematuramente para no poner en riesgo a los usuarios.
- Informar al fabricante a trav茅s de los canales establecidos.
- Facilitar la investigaci贸n con informaci贸n adicional cuando se solicita.
- Respetar los plazos de coordinaci贸n que la empresa propone.
- Permitir que el proveedor prepare una soluci贸n antes de la publicaci贸n.
- Documentar sus conclusiones de forma responsable y precisa.
Y, en muchos casos, el investigador hace todo esto sin ninguna garant铆a de reconocimiento, parche o recompensa. Lo hace porque cree en el modelo. Porque entiende que la seguridad es una responsabilidad compartida.
La l贸gica es impecable. Pero esa misma l贸gica deber铆a funcionar en ambas direcciones.
2. El problema aparece cuando nadie es responsable y a la vez, lo son todas las partes inplicadas
Durante una investigaci贸n pueden aparecer problemas que atraviesan diferentes capas de un sistema. Un mismo comportamiento puede involucrar:
- Aplicaci贸n (el software que el usuario ve)
- Framework (la capa intermedia que soporta la aplicaci贸n)
- Biblioteca nativa (c贸digo de bajo nivel, a menudo en C/C++)
- Sistema operativo (el n煤cleo del sistema)
- Fabricante / OEM (personalizaciones del sistema)
Y tambi茅n:
- Producto A (ej. Chrome, Firefox, Edge)
- Producto B (ej. Android)
- Componente compartido (ej. libminikin)
- Infraestructura com煤n (ej. Binder, IPC)
- Servicio en la nube (ej. Llm's API)
Entonces aparece el fen贸meno conocido por muchos investigadores:
“No es nuestro problema.”
Un equipo o vendor, puede indicar: “Esto es un problema de Android.”
Android puede responder: “No est谩 dentro del alcance de nuestro programa.”
Otro equipo puede a帽adir: “Debe reportarse al producto correspondiente.”
Y el investigador vuelve al punto de partida.
El atacante no necesita saber qu茅 equipo es responsable. El investigador tampoco deber铆a tener que resolver el organigrama interno de una multinacional para encontrar al responsable. Si el problema atraviesa capas, el atacante ve un sistema. El investigador ve un sistema. La organizaci贸n, sin embargo, puede verlo como tres equipos o m谩s distintos.
3. El caso STA: una investigaci贸n transversal
Mi investigaci贸n sobre Structured Text Amplification (STA) comenz贸 en 2022, estudiando comportamientos relacionados con texto estructurado y agotamiento de recursos en Android. Lo que parec铆a un problema aislado en una biblioteca fue revelando un patr贸n m谩s amplio.
Con el tiempo, aparecieron diferentes manifestaciones en distintos componentes:
| Componente |
S铆ntoma |
Mecanismo |
| libminikin.so |
ANR, bloqueo del hilo principal |
Knuth-Plass O(n²) |
| Binder / SavedState |
TransactionTooLargeException, crash loops |
Serializaci贸n O(n²) |
| Llm's (modelo) |
Instruction Drift, generaci贸n de contenido sin contexto |
Atenci贸n O(n²) |
| Llm's (cliente) |
ANR, UI freeze |
libminikin O(n²) |
| Navegadores |
Bloqueo de renderizado |
Algoritmos de layout O(n²) |
Lo interesante no era cada fallo individual, sino la posibilidad de que existiera un patr贸n com煤n:
Entrada estructurada (texto repetitivo, baja entrop铆a)
↓
Transformaci贸n (tokenizaci贸n, layout, serializaci贸n)
↓
Amplificaci贸n del coste (algoritmo O(n²))
↓
Agotamiento de recursos (CPU, memoria, tiempo)
↓
P茅rdida de disponibilidad (ANR, crash, DoS)
Este patr贸n aparec铆a en el cliente Android (la apps de Google, Mozilla, Meta, Microsoft, Xiaomi, entre otros). Aparec铆a en el sistema operativo (libminikin, Binder). Y, m谩s tarde, apareci贸 tambi茅n en los Llm's, tanto en el modelo (p茅rdida de contexto) como en el cliente (ANR al renderizar respuestas largas o tareas simples como contar caracteres ).
El problema era real, reproducible y estaba documentado con stacktraces, m茅tricas de sistema y pasos concretos. Pero al intentar reportarlo siguiendo los cauces establecidos, ocurri贸 lo que muchos investigadores han vivido:
- VRP's: “Fuera de alcance.”
- llm's VRP: “Bypass de guardrail de seguridad. Fuera de alcance.”
- Feedback in-product: Canal adecuado, pero sin garant铆a de respuesta o mitigaci贸n.
El patr贸n STA exist铆a. Las evidencias eran s贸lidas. Pero la responsabilidad quedaba diluida entre equipos, programas y criterios.
4. La anatom铆a de una derivaci贸n
Para entender el problema, es 煤til analizar qu茅 ocurre cuando un reporte atraviesa el sistema de gesti贸n de vulnerabilidades de una gran organizaci贸n.
Fase 1: Recepci贸n
El investigador env铆a un informe detallado. Recibe un acuse de recibo autom谩tico. El reporte entra en una cola de triaje.
Fase 2: Triaje inicial
Un revisor, a menudo con poco tiempo y muchos reportes, clasifica el problema. Si encaja en un patr贸n conocido, puede ser asignado a un equipo. Si no, puede ser rechazado por “falta de informaci贸n” o “no reproducible”.
Fase 3: An谩lisis t茅cnico
El equipo asignado analiza el problema. Si el equipo es el correcto, la investigaci贸n avanza. Si el problema cruza fronteras, aparece la pregunta: “¿Es realmente nuestro?”
Fase 4: Derivaci贸n
El problema se traslada a otro equipo. Ese equipo, a su vez, puede derivarlo a otro. Cada derivaci贸n reinicia parcialmente el proceso. Cada equipo aplica sus propios criterios.
Fase 5: Decisi贸n final
En alg煤n punto, el problema es clasificado como “fuera de alcance”, “no elegible para recompensa” o “no reproducible”. El investigador recibe una respuesta. El problema sigue existiendo.
Lo parad贸jico es que cada decisi贸n individual puede ser razonable. Cada equipo puede tener argumentos v谩lidos para no asumir la responsabilidad. Pero el resultado final es que el problema no se soluciona.
Y el investigador, que empez贸 con la intenci贸n de ayudar, se encuentra con un muro de silencio.
5. “Out of scope” no significa “el problema no existe”
Hay una confusi贸n conceptual que conviene aclarar.
Un programa de recompensas puede establecer leg铆timamente qu茅 tipos de problemas son elegibles para recompensa. Esa es una decisi贸n de alcance. Es razonable que una empresa defina los l铆mites de su programa.
Pero:
No elegible para recompensa ≠ inexistente.
Un problema puede quedar fuera de un VRP y seguir siendo:
- Reproducible.
- T茅cnicamente relevante.
- Peligroso para determinados usuarios.
- Digno de una mitigaci贸n.
- Digno de una investigaci贸n interna.
- Digno de ser documentado p煤blicamente.
Esta distinci贸n es fundamental. Un programa de recompensas puede rechazar un reporte por alcance, pero eso no significa que el equipo de producto deba ignorarlo.
El problema ocurre cuando “fuera de alcance” se convierte en un sin贸nimo de “no es responsabilidad nuestra” y cuando esa falta de responsabilidad impide que el problema se solucione.
6. El coste de la investigaci贸n independiente
Para entender la asimetr铆a, hay que considerar los recursos de cada parte.
Una gran organizaci贸n puede disponer de:
- Equipos especializados en diferentes 谩reas.
- Acceso al c贸digo fuente completo.
- Infraestructura de reproducci贸n a gran escala.
- Telemetr铆a para identificar la prevalencia del problema.
- Ingenieros dedicados a tiempo completo.
- Herramientas internas de an谩lisis y depuraci贸n.
- Capacidad para parchear millones de dispositivos en d铆as o semanas.
- Departamento legal para gestionar riesgos.
- Presupuesto para recompensas y reconocimiento.
El investigador independiente, en cambio, puede disponer de:
- Un ordenador (a menudo personal).
- Un tel茅fono (a menudo personal).
- Unos bugreport (obtenidos con esfuerzo).
- Una conexi贸n a Internet.
- Y muchas horas de trabajo no remunerado.
En mi caso, buena parte de esta investigaci贸n se ha realizado desde un entorno dom茅stico. No hay un laboratorio detr谩s, ni un departamento legal, ni un equipo de ingenier铆a esperando para validar cada hip贸tesis. La validaci贸n de las evidencias recae enteramente en el investigador.
Y, sin embargo, el investigador debe proporcionar evidencia suficientemente s贸lida para que una organizaci贸n pueda tomar una decisi贸n. La exigencia es leg铆tima. La reciprocidad deber铆a serlo tambi茅n.
7. Cuando la evidencia contradice la respuesta inicial
Una de las situaciones m谩s reveladoras ocurre cuando la primera conclusi贸n de la organizaci贸n es:
Pero posteriormente aparecen:
- Nuevos dispositivos donde el problema se manifiesta.
- Nuevos dumps con stacktraces adicionales.
- Nuevos ANR traces en el mismo componente.
- Nuevas aplicaciones afectadas por el mismo patr贸n.
- Nuevas reproducciones que confirman la hip贸tesis.
- Evidencia del mismo componente en diferentes contextos.
- Comportamiento consistente entre productos.
Entonces la pregunta ya no deber铆a ser:
“¿Por qu茅 el investigador insiste?”
La pregunta deber铆a ser:
“¿Qu茅 hemos aprendido desde la primera evaluaci贸n?”
La seguridad no deber铆a funcionar como un juicio que termina con la primera decisi贸n. Deber铆a funcionar como un proceso iterativo:
Hip贸tesis inicial
↓
Evidencia recopilada
↓
Reproducci贸n en condiciones controladas
↓
An谩lisis t茅cnico
↓
Nueva evidencia (m谩s dispositivos, m谩s contextos)
↓
Reevaluaci贸n de la hip贸tesis
↓
Actualizaci贸n de la decisi贸n
Este ciclo es com煤n en la investigaci贸n cient铆fica. En la seguridad, sin embargo, tiende a ser lineal: una decisi贸n inicial, sin espacio para la reevaluaci贸n.
8. La paradoja de la coordinaci贸n
Cuando una organizaci贸n solicita coordinaci贸n, el mensaje es claro:
“Danos tiempo para investigar y solucionar el problema.”
El investigador acepta. Pero la coordinaci贸n implica una segunda obligaci贸n: utilizar ese tiempo de forma efectiva.
La coordinaci贸n no deber铆a significar:
Investigador
↓
Reporte (con evidencia)
↓
Espera (semanas o meses)
↓
"No reproducible"
↓
Investigador aporta m谩s evidencia
↓
Espera
↓
"Out of scope"
↓
Investigador apela
↓
Espera
↓
"Pertenece a otro equipo"
↓
Investigador reporta al otro equipo
↓
El ciclo se reinicia
Eso no es coordinaci贸n. Es derivaci贸n de responsabilidad. Es un laberinto donde el investigador es el 煤nico que recorre todas las salas, mientras la organizaci贸n mantiene sus puertas cerradas.
9. Una contradicci贸n evidente
Al investigador se le dice:
Perfecto. Es razonable.
Pero si despu茅s de meses o a帽os la respuesta contin煤a siendo:
“No es nuestro problema.”
¿Durante cu谩nto tiempo debe permanecer el investigador en silencio?
- ¿Qui茅n protege al usuario durante ese periodo?
- ¿Qui茅n asume el riesgo de que el problema sea explotado?
- ¿Qui茅n decide que el problema merece atenci贸n?
- ¿Qui茅n determina si el problema es “suficientemente grave”?
- ¿D贸nde termina la responsabilidad del investigador y empieza la responsabilidad del fabricante?
El modelo actual responde a estas preguntas de forma impl铆cita:
“El investigador es responsable de no divulgar. El fabricante es responsable de decidir si el problema existe.”
Pero la decisi贸n de “si el problema existe” no deber铆a ser una decisi贸n unilateral, especialmente cuando el investigador ha aportado evidencia s贸lida y reproducible.
10. La responsabilidad no puede viajar solo en una direcci贸n
El modelo actual puede resumirse as铆:
| Investigador |
Organizaci贸n |
| Reproducir el problema |
Investigar t茅cnicamente |
| Documentar con evidencias |
Validar la informaci贸n |
| Reportar a trav茅s de los canales |
Responder en tiempo razonable |
| Coordinar la divulgaci贸n |
Coordinar la correcci贸n |
| Esperar el tiempo necesario |
Actuar sobre el problema |
| No divulgar prematuramente |
Mitigar el riesgo |
| Facilitar informaci贸n adicional |
Asumir responsabilidad |
El problema aparece cuando la segunda columna se convierte en:
“No corresponde a nuestro programa.”
“No es elegible para recompensa.”
“Pertenece a otro equipo.”
Entonces la primera columna sigue teniendo todas las obligaciones, mientras que la segunda conserva 煤nicamente la posibilidad de rechazar el caso.
Eso es una asimetr铆a estructural. No es un fallo de una empresa concreta. Es un fallo del modelo.
11. La recompensa tampoco deber铆a ser el centro
Hay una cuesti贸n especialmente importante que suele pasarse por alto.
La investigaci贸n de seguridad no deber铆a reducirse a:
Hay investigadores que buscan dinero. Otros buscan reconocimiento. Otros simplemente quieren que el problema se arregle. Algunos investigan porque quieren comprender c贸mo funcionan los sistemas y compartir ese conocimiento.
Por eso una respuesta como:
“No es elegible para recompensa”
no deber铆a cerrar necesariamente la conversaci贸n t茅cnica.
Podr铆a existir otra respuesta:
“No podemos recompensarlo seg煤n las reglas del programa, pero hemos identificado el problema y vamos a mitigarlo.”
“Hemos derivado el problema al equipo de producto para que lo eval煤e en futuras versiones.”
Esa ser铆a una respuesta mucho m谩s saludable para el ecosistema.
12. El silencio como estrategia
Hay una realidad inc贸moda que pocos investigadores mencionan abiertamente.
En algunos casos, el silencio —o la derivaci贸n, no es un fallo del sistema, sino una estrategia deliberada.
Si un problema no se clasifica como vulnerabilidad, no hay obligaci贸n de parchearlo.
Si el problema se deriva a otro equipo, la responsabilidad queda en suspenso.
Si el investigador se cansa y desiste, el problema desaparece del radar.
Esta estrategia no requiere mala fe. Puede ser simplemente el resultado de equipos que trabajan bajo presi贸n, con recursos limitados, y que priorizan los problemas que encajan en sus m茅tricas.
Pero el efecto es el mismo: el problema no se soluciona.
13. El investigador independiente no tiene voz en la decisi贸n
Una de las asimetr铆as m谩s profundas es la siguiente:
El investigador aporta el descubrimiento. Aporta la evidencia. Aporta el tiempo. Aporta la paciencia. Aporta la buena fe.
Pero no tiene voz en la decisi贸n final.
- No decide si el problema es “suficientemente grave”.
- No decide si merece un parche.
- No decide cu谩ndo se solucionar谩.
- No decide si se reconocer谩 su trabajo.
- No decide si se comunicar谩 p煤blicamente.
La organizaci贸n tiene todas esas decisiones. El investigador tiene solo la decisi贸n de publicar o no publicar.
Y esa decisi贸n, publicar, est谩 cargada de riesgos: legales, reputacionales, y de relaci贸n con futuros reportes.
14. Divulgaci贸n coordinada no es silencio coordinado
Existe una diferencia esencial entre ambas cosas:
Divulgaci贸n coordinada:
“Tenemos un problema. Trabajemos juntos para entenderlo, mitigarlo y comunicarlo de forma responsable.”
Silencio coordinado:
“El problema est谩 reportado, pero nadie quiere asumir la responsabilidad. El investigador espera. El problema sigue existiendo.”
La primera protege a los usuarios. La segunda protege principalmente al proceso.
La primera es colaboraci贸n. La segunda es inacci贸n.
Y la seguridad deber铆a estar dise帽ada para proteger a los usuarios, no los procesos internos.
15. El caso STA como ejemplo de un problema m谩s amplio
STA no es una excepci贸n. Es un ejemplo de lo que ocurre cuando un comportamiento atraviesa diferentes capas de un ecosistema y la responsabilidad queda fragmentada.
En mi investigaci贸n, el mismo patr贸n apareci贸 en:
- Android (libminikin, Binder, SavedState).
- Llm's (modelo y cliente).
- Aplicaciones de terceros (WhatsApp, navegadores).
- Componentes compartidos (StaticLayout, LineBreaker).
Cada uno de estos dominios tiene sus propios equipos, sus propios programas de recompensas, sus propios criterios y sus propias prioridades.
Pero el patr贸n subyacente es el mismo. Es la misma entrada estructurada, la misma amplificaci贸n de coste, el mismo agotamiento de recursos.
Sin embargo, cuando intent茅 reportarlo de forma transversal, me encontr茅 con que:
- VRP's lo consideraron “fuera de alcance”.
- llm's VRP lo consideraron “safety guardrail bypass”.
- El feedback in-product no garantiza respuesta ni mitigaci贸n.
- El problema sigue existiendo.
STA no es un problema de un equipo. Es un problema de arquitectura. Y los problemas de arquitectura no se solucionan derivando responsabilidades.
16. Lo que deber铆a cambiar
Para que la divulgaci贸n coordinada funcione de forma efectiva, se necesitan algunos cambios en el modelo actual:
a. Puntos de entrada transversales
Las grandes organizaciones deber铆an tener puntos de entrada para problemas que cruzan equipos. Un equipo central de triaje que pueda evaluar un problema t茅cnico sin necesidad de que el investigador conozca el organigrama interno.
b. Distinci贸n clara entre “alcance” y “existencia”
Que un problema no sea elegible para recompensa no deber铆a impedir que el equipo de producto lo eval煤e y, si es necesario, lo mitigue.
c. Procesos de reevaluaci贸n
Si el investigador aporta evidencia adicional que contradice una decisi贸n inicial, deber铆a existir un proceso para reabrir la investigaci贸n sin necesidad de reiniciar todo el ciclo.
d. Comunicaci贸n transparente
Si el problema se deriva a otro equipo, el investigador deber铆a ser informado de forma clara, con un punto de contacto o un identificador de seguimiento.
e. Reconocimiento sin recompensa
Si el problema no cumple los criterios de recompensa, pero es t茅cnicamente relevante, la organizaci贸n deber铆a poder ofrecer un reconocimiento simb贸lico (menci贸n en los agradecimientos, nota en las release notes, etc.).
17. Una pregunta inc贸moda (y su respuesta)
Despu茅s de a帽os investigando vulnerabilidades, con mas de
400 descubiertas y documentadas y mas de 80 CVE, observando este patr贸n, hay una pregunta que considero inevitable:
¿Qu茅 debe hacer un investigador cuando ha cumplido con todas las reglas de la divulgaci贸n responsable, pero ninguna organizaci贸n acepta la responsabilidad de solucionar el problema?
No tengo una respuesta sencilla. Pero s铆 tengo una conclusi贸n:
La responsabilidad no puede exigirse unilateralmente.
Si se espera que el investigador act煤e responsablemente para proteger a los usuarios, las organizaciones deben hacer lo mismo. La seguridad no es un juego de trileros donde la responsabilidad se pasa de una mano a otra hasta que el investigador se cansa.
El investigador debe asumir su parte. Pero la organizaci贸n tambi茅n.
18. El objetivo final
No se trata de ganar una discusi贸n. No se trata de conseguir una recompensa. No se trata de demostrar que una empresa se equivoc贸.
Se trata de algo mucho m谩s sencillo:
Que el problema deje de existir.
- Si una vulnerabilidad puede solucionarse, solucion茅mosla.
- Si no es vulnerable, demostremos por qu茅.
- Si est谩 fuera del alcance de un programa, deriv茅mosla al equipo adecuado.
- Si el impacto no alcanza el umbral de una recompensa, eso no impide investigarla.
Pero no deber铆amos permitir que el 煤ltimo paso sea:
“Este problema pertenece a otro.”
Porque entonces el problema sigue perteneciendo a todos. Y, al final, a nadie.
19. Una llamada a la responsabilidad compartida
La divulgaci贸n responsable naci贸 como un pacto de confianza entre investigadores y fabricantes. Ese pacto sigue siendo necesario. Pero la confianza funciona en ambas direcciones.
El investigador debe asumir responsabilidad por lo que descubre.
- Investigar con rigor.
- Documentar con precisi贸n.
- Reportar con buena fe.
- Coordinar con paciencia.
- Divulgar con responsabilidad.
Las empresas deben asumir responsabilidad por lo que construyen.
- Responder con seriedad.
- Investigar cuando exista evidencia suficiente.
- Distinguir entre “fuera de alcance” y “no existe”.
- Evitar derivaciones infinitas.
- Proporcionar puntos de contacto adecuados.
- Informar cuando la investigaci贸n contin煤a.
- Mitigar cuando sea necesario.
Cuando un investigador entrega evidencia reproducible, concede tiempo y respeta los mecanismos de coordinaci贸n, la respuesta no deber铆a ser una cadena infinita de derivaciones.
Deber铆a existir una puerta de entrada.
Alguien que diga:
“Entendido. Nosotros nos encargamos de averiguar qui茅n debe solucionarlo.”
Porque esa es precisamente la diferencia entre gestionar un reporte y gestionar un riesgo de seguridad.
Conclusi贸n: la seguridad no es un juego de trileros
La seguridad inform谩tica es un campo que se basa en la confianza. Confiamos en que los fabricantes corrigen los problemas que les reportamos. Confiamos en que los investigadores no explotan las vulnerabilidades antes de que se solucionen.
Pero la confianza no es un recurso infinito. Se agota cuando una de las partes no cumple su parte.
La divulgaci贸n coordinada no deber铆a ser una excusa para que las empresas trasladen todo el riesgo al investigador. No deber铆a ser un mecanismo para silenciar problemas inc贸modos. No deber铆a ser un laberinto del que el investigador no pueda salir.
Deber铆a ser un proceso colaborativo donde ambas partes asumen sus responsabilidades para proteger a los usuarios.
El investigador descubre. El fabricante corrige.
Y el usuario, al final, est谩 protegido.
Ese es el objetivo. No deber铆amos perderlo de vista.
Como final del art铆culo dir茅: si clicar en un enlace causa el crash wn una aplicaci贸n y esta aplicaci贸n hace caer SystemUI y a su vez causa un loop de reinicios y se la interfaz y obliga al sistema a borrar sus propios datos de estado etc y de la que un usuario normal no sabe recuperarse, no es un problema de seguridad entonces que es?
Manuel Garc铆a Pe帽a (Lostmon) — Independent Security Researcher
Agosto de 2026
Posts
