Apache 2.4.67 satte ældre reverse proxies tilbage på risikolisten

Af Greg Nowak. Senest opdateret 2026-07-13.

Apache 2.4.67, der blev udgivet den 4. maj 2026, var ikke en almindelig vedligeholdelsesversion. Den rettede en alvorlig HTTP/2 double-free-fejl i 2.4.66 med mulighed for fjernudførelse af kode, flere fejl i AJP-parsingen, et rettighedsproblem i .htaccess og svagheder i proxy-modulernes håndtering af ondsindede svar fra backends. Tilsammen var det en nyttig advarsel til virksomheder med en Apache-server, som ingen tænker på, før trafikken går i stå.

Det var ikke en version, man burde blive på. Pr. 13. juli 2026 er Apache 2.4.68 den seneste upstream-version, og den anbefales frem for tidligere 2.4.x-versioner. Den retter yderligere sårbarheder, der påvirker 2.4.67, herunder problemer i mod_proxy_html, ProxyPassReverseCookie*, delegerede .htaccess-udtryk og mod_http2. Hvis 2.4.67 satte gang i jeres gennemgang, var det nyttigt. Målet bør nu være 2.4.68 eller en vedligeholdt distributionspakke, der udtrykkeligt indeholder de samme rettelser.

Risikoen ligger i serverens rolle, ikke kun i dens version

En ældre reverse proxy kan terminere TLS, omdirigere gamle domæner, håndhæve adgangsregler, videresende authentication-headers og forbinde offentlige requests med et ERP-, CMS- eller Java-system. Konfigurationen fungerer derfor både som sikkerhedsgrænse, routingtabel og forretningshistorik. En kompromitteret backend kan muligvis udnytte sårbar proxy-kode, mens en for lempelig .htaccess-politik kan give lokale indholdsansvarlige flere beføjelser end tilsigtet.

Prioritér efter eksponering og funktion frem for blot at tælle Apache-installationer:

Indikator	Anbefalet beslutning	Hvorfor det er vigtigt
2.4.67 eller tidligere håndterer offentlig trafik	Opdatér nu via den understøttede pakkekanal, genstart, og verificér den kørende tjeneste.	2.4.68 retter sårbarheder, der stadig findes i 2.4.67.
`Protocols h2` er aktiveret	Opdatér, test derefter samtidige forbindelser, og kontrollér den tilgængelige kapacitet for threads, hukommelse og file descriptors.	`mod_http2` har sine egne workers og var berørt af yderligere sikkerhedsrettelser i 2.4.68.
AJP eller proxy-moduler til omskrivning af indhold er indlæst	Fjern ubrugte moduler, og begræns og dokumentér de nødvendige backend-forbindelser.	Flere af problemerne involverer ondsindede eller kompromitterede upstream-tjenester.
Teams kan redigere `.htaccess`	Identificér alle med skriveadgang, og begræns de tilladte directives.	Delegeret konfiguration er en sikkerhedsbeslutning, ikke blot en bekvemmelighed.
`ProxyRequests On` forekommer	Bekræft, at en kontrolleret forward proxy er tilsigtet og korrekt begrænset.	En almindelig reverse proxy bør ikke utilsigtet acceptere vilkårlige proxy-requests.

En praktisk prioriteringsmatrix til at afgøre, hvilke Apache-hosts der først kræver opmærksomhed.

Kortlæg proxyen, før du ændrer den

Begynd på hosten eller på en nøjagtig staging-kopi med en lille dokumentationspakke:

apachectl -v
apachectl -M
apachectl -S
apachectl -t
grep -RniE 'Protocols|ProxyRequests|ProxyPass|AllowOverride|AllowOverrideList|ajp://' /etc/apache2 /etc/httpd 2>/dev/null

Kommandoerne viser versionen af den eksekverbare fil, indlæste moduler, virtual-host-kortet, konfigurationens grundlæggende gyldighed og sandsynlige regler for HTTP/2, proxy og delegering. Outputtet fra grep er kun til indledende vurdering: Det kan indeholde kommentarer og inaktive filer eller overse konfiguration, der er gemt andre steder.

Brug ikke versionsbanneret alene som dokumentation for patch-status. Linux-leverandører kan backporte rettelser uden at ændre upstream-versionen på den måde, du forventer. Sammenlign den fulde revision af den installerede pakke med leverandørens sikkerhedskanal, og bekræft, at Apache blev genstartet efter opdateringen. Registrér, hvilket offentligt hostname der fører til hvilken backend, hvem der ejer den, hvordan dens tilstand kontrolleres, og hvordan der rulles tilbage.

Behandl opdateringen som en kontrolleret forretningsændring

Pakkeinstallationen er som regel den korteste del af arbejdet. Den væsentlige opgave er at dokumentere, at de forretningskritiske flows stadig fungerer korrekt:

Registrér de installerede pakkeversioner, en backup af konfigurationen og rollback-proceduren før vedligeholdelsesvinduet.
Test kanoniske redirects, authentication, uploads, API-kald, WebSockets, hvor de bruges, admin-ruter og upstream-TLS – ikke kun forsiden.
Test både HTTP/1.1 og HTTP/2. Virtual hosts, der deler certifikat og bruger HTTP/2, skal have ensartede TLS-indstillinger, ellers kan klienter modtage 421 Misdirected Request.
Kontrollér adfærden, når en backend er langsom eller utilgængelig. Bekræft, at timeouts og fejlsider ikke afslører interne hosts eller skaber retry-storme.
Verificér efter udrulningen den kørende proces, gennemgå fejl- og access-logs, overvåg ressourceforbruget, og sæt en fast tidsgrænse for beslutningen om rollback.

Brug vedligeholdelsesvinduet til at gøre den næste opdatering billigere

Deaktivér ikke automatisk HTTP/2, og erstat ikke AJP, blot fordi et modul er nævnt i forbindelse med en sårbarhed. Fastslå først, om funktionen er nødvendig, og om hosten har tilstrækkelig kapacitet og passende kontrol med backends. Hvis AJP kun findes, fordi en gammel applikation engang krævede det, skal planen for udfasning have en ansvarlig og en dato.

Når administratorerne har kontrol over Apaches hovedkonfiguration, anbefaler Apache at foretrække den frem for .htaccess. Hvis delegering reelt er nødvendig, kan AllowOverrideList tillade navngivne directives frem for brede kategorier. Hold større oprydning adskilt fra den akutte sikkerhedsopdatering, hvis en kombination vil gøre test eller rollback uklar.

Det bør en nyttig vedligeholdelsesgennemgang efterlade

Dokumentation for den opdaterede pakke og den genstartede proces
En kortfattet oversigt over moduler, virtual hosts og backends
Registrerede testresultater fra før og efter ændringen
En rollback-runbook og en prioriteret oprydningsliste med ansvarlige

Det forvandler en akut opdatering til en driftsopgave, der kan gentages. Hvis en overtaget Apache-proxy står mellem jeres kunder og systemer, som jeres team ikke med sikkerhed kan kortlægge, kan Greg hjælpe med at afgrænse gennemgangen, koordinere det tekniske arbejde og give det næste team en brugbar runbook.

Relateret på GrN.dk

Har du brug for hjælp til denne type arbejde?

Drøft din vedligeholdelsesplan for Apache – kontakt Greg.

Kilder

Sidst ændret

2026-08-31