AISLE publiserte 28. april funn fra en autonom analyse av OpenEMR, den ONC-sertifiserte open-source-journalplattformen som 100 000 leger og 200 millioner pasienter er avhengige av. Analyzeren, samme motor som tidligere fant tolv nulldagshull i OpenSSL, avdekket 38 nye CVE-er i Q1 2026. Til sammenligning fant Project Insecurity-rapporten i 2018 23 sårbarheter etter et lengre manuelt arbeid. AISLEs motor fant 38 på ett kvartal og leverte automatiske patch-forslag for hvert eneste tilfelle.
Funnene fordeler seg på tre familier: manglende autorisasjon (IDOR-feil, ACL-bypass og en endpoint som hoppet over autentisering helt), lagret og refleksiv XSS, og to kritiske SQL-injeksjoner. Den verste, CVE-2026-24908, lå i _sort-parameteren i Patient REST API, hvor input ble limt rett inn i ORDER BY-klausuler uten validering. Med database-bruker som hadde FILE-privilegier kunne det eskaleres til vilkårlig fillesing og fjernkjøring av kode. CVE-2026-23627 i Immunization-modulen tillot tilsvarende UNION-baserte injeksjoner via web-grensesnittet.
«For et prosjekt som OpenEMR, der innsatsene er pasientsikkerhet og helseinformasjon, kunne vi ikke vært mer fornøyde med samarbeidet. Nå med Aisles analyzer på code review-stadiet fanger vi sårbarheter før de når produksjon.» — Brady Miller, MD, Executive Director i OpenEMR Foundation
Det praktisk interessante for deg som bygger eller vurderer agent-baserte sikkerhetsverktøy er ikke bare antallet, men arbeidsflyten. AISLE genererte repository-native patch-forslag som gjenbrukte OpenEMRs egne sanitiserings-helpers og autorisasjonsmønstre. For den kritiske CVE-2026-23627 produserte AISLE selve fiksen uavhengig. Det er en konkret demonstrasjon av at LLM-baserte sårbarhetsanalyser kan flytte fra deteksjon til remediering uten å rive ned eksisterende kode-konvensjoner.
«Defendere trenger samsvarende dekning. OpenEMR-engasjementet er hva det ser ut som i praksis: en autonom analyzer som finner ekte sårbarheter i kritisk programvare, fikser landet i produksjon i løpet av uker, og samme system flyttet oppstrøms til å fange nye sårbarheter ved code review.» — Stanislav Fort, AISLE
For norske utviklere er det to konkrete signaler. Hvis du selvhoster OpenEMR, må du oppgradere. Hvis du bygger et internt agent-rammeverk for kodegjennomgang, er AISLE-tilnærmingen et sterkt referansepunkt: deterministisk linter først, så LLM-drevne sub-agenter på top. Samme mønster er lett overførbart til andre språk og stacker.
Hva bør du gjøre?
- Oppgrader OpenEMR-instansen din til 8.0.0 eller nyere. Hovedtyngden av AISLE-fiksene shippet 11. februar, resten i tre patch-utgivelser i mars. Sjekk changelog-en mot din nåværende versjon.
- Inventarier hvilke database-brukere som har
FILE-privilegier. Flere av SQL-injeksjonene ble kritiske kun fordi tilkoblingsbrukeren hadde mer enn nødvendig. Prinsippet om minste privilegium er gratis defense-in-depth. - Studer AISLEs tilnærming hvis du bygger interne audit-agenter. Den åpne advisory-listen viser hvilke kategorier (autorisasjon, XSS, SQL, sti-traversering) som dominerer i en moden PHP-kodebase, og det er nyttig kalibrering for egne regelsett.
Bakgrunn
AISLE startet engasjementet med OpenEMR-vedlikeholderne i midten av desember 2025 og rapporterte første batch midt i januar 2026. I tidlig april ble samarbeidet formalisert ved at AISLE PRO, deres KI-baserte commit-analyzer, ble integrert i OpenEMRs code review-arbeidsflyt. Mønsteret «autonom audit pluss menneskelig vedlikeholder» går fra eksperiment til praksis i raskere tempo enn de fleste forventet i fjor.