Apache 2.4.68 viser, at gamle proxyregler kræver en grundig revision

Af Greg Nowak. Senest opdateret 2026-06-17.

Apache HTTP Server 2.4.68, der blev udgivet den 8. juni 2026, beskrives officielt af projektet som en udgivelse med sikkerhedsrettelser, nye funktioner og fejlrettelser, og Apache anbefaler den frem for alle tidligere versioner. På papiret gør det opgraderingen til almindelig vedligeholdelse. I praksis fortæller udgivelsen driftsansvarlige noget mere nyttigt: Risikoen i ældre Apache-miljøer ligger ofte begravet i årevis af nedarvede proxyregler, indlæste moduler og antagelser om backends, som ingen har gennemgået fra ende til anden.

Listen over sårbarheder i 2.4.68 er et godt eksempel. Der er ikke tale om én isoleret fejl i ét obskurt modul. Den omfatter mod_proxy, mod_http2, mod_ssl, DAV, LDAP, XML, headerbehandling og håndtering af privilegier i .htaccess. Hvis Apache ligger i kanten af din stack, har denne bredde betydning. Det betyder, at det egentlige spørgsmål ikke kun er, om du hurtigt kan installere en patch. Det er også, om den nuværende konfiguration stadig fortjener din tillid.

Derfor bør udgivelsen føre til en revision – ikke kun et vedligeholdelsesvindue

Alene i proxy-laget retter 2.4.68 en cross-site scripting-sårbarhed i mod_proxy_ftp, et buffer overflow i mod_proxy_html, når en backend, der ikke er tillid til, er involveret, samt et heap-baseret buffer overflow knyttet til ProxyPassReverseCookie*-direktiver med ondsindede backendservere. Samme udgivelse retter også CVE-2026-49975, en denial-of-service-sårbarhed med moderat alvorlighed, som påvirker Apache HTTP Server version 2.4.17 til og med 2.4.67, samt endnu en memory corruption-fejl i mod_http2, der påvirker 2.4.55 til og med 2.4.67.

Denne spredning er vigtigere end klassificeringen af en enkelt CVE. Den berører omskrivning af svar i reverse proxies, omskrivning af cookies, HTTP/2-håndtering, udgående OCSP-adfærd i mod_ssl og lokale privilegiegrænser i .htaccess. Det er et realistisk tværsnit af, hvordan Apache anvendes i produktion. Apaches egen meddelelse gør også den driftsmæssige situation tydelig: 2.4.68 er den aktuelle GA-udgivelse, mens 2.2-grenen for længst har nået end-of-life og ikke længere modtager sikkerhedsrettelser. Hvis en platform stadig bærer rundt på konfigurationsvaner fra 2.2-tiden, er den 8. juni 2026 et fornuftigt tidspunkt at holde op med at betragte dem som forældede, men harmløse.

Revisionsområde	Det fremhæver 2.4.68	Det bør kontrolleres nu
Proxy-moduler	Rettelserne berører mod_proxy_ftp, mod_proxy_html og håndteringen af ProxyPassReverseCookie*. Apache 2.4 opdelte desuden load balancing i individuelle mod_proxy-undermoduler.	Registrér alle indlæste proxy-undermoduler, samtlige ProxyPass-stier og enhver omskrivning af cookies eller HTML, som afhænger af tillid til en backend.
HTTP/2	Udgivelsen indeholder to rettelser til mod_http2, herunder CVE-2026-49975 for version 2.4.17 til og med 2.4.67.	Test HTTP/2-adfærden i staging med ugyldige requests, backendfejl og begrænsede ressourcer – ikke kun med normal trafik.
Auth og .htaccess	Apaches vejledning til 2.4 advarer mod at blande gamle Order/Allow/Deny-regler med Require, og 2.4.68 retter en privilege escalation-sårbarhed i .htaccess.	Gennemgå AllowOverride og AllowOverrideList, og ryd derefter bevidst op i auth-blokke fra forskellige generationer i stedet for at videreføre dem uændret.
MPM og runtime-model	Apache 2.4 understøtter indlæsbare MPM'er, har fuld understøttelse af Event MPM og advarer om, at threaded MPM'er kræver thread-safe moduler og biblioteker.	Kontrollér, at den aktive MPM er valgt bevidst, og at alle indlæste moduler og afhængigheder passer til den pågældende threading-model.

En praktisk tjekliste til Apache-miljøer, som videresender trafik gennem proxies, tilbyder HTTP/2 eller stadig benytter ældre mønstre for adgangskontrol.

Det er i ældre syntaks, at stille regressioner har det med at overleve

Apaches egen opgraderingsvejledning er usædvanligt direkte om ændringerne i authorization. Den fastslår, at enhver konfiguration, som bruger authorization, sandsynligvis skal ændres, og anbefaler, at den gamle model med Order, Allow, Deny og Satisfy erstattes med authorization-frameworket i 2.4. Kompatibilitet er mulig via mod_access_compat, men Apache fraråder udtrykkeligt at blande disse ældre direktiver med Require. Vejledningen viser endda en konkret fejltilstand: En server-status-location, der ser ud til at være tilladt lokalt, returnerer alligevel HTTP 403, fordi kompatibilitetsdirektiverne har forrang i dette merge-scenarie.

Det er den slags problemer, som slipper igennem ved rutinemæssige opgraderinger. En server kan køre en aktuel version og stadig opføre sig, som om migreringen fra 2.2 kun er delvist gennemført. Det samme gælder kombineret logik til authentication og adgangskontrol. I 2.4 flyttes mønstre, der tidligere var baseret på Satisfy ALL eller Satisfy any, til RequireAll eller standardadfærden RequireAny. Hvis reglerne er blevet kopieret mellem vhosts gennem flere år, handler risikoen ikke kun om læsbarhed. Risikoen er, at det nuværende team tror, at reglerne fungerer på én måde, mens Apache i praksis evaluerer dem på en anden.

Proxy-tunge stacks får størst udbytte af forenkling

Funktionssættet i Apache 2.4 er endnu et fingerpeg om, at gamle proxyregler fortjener en grundig gennemgang. Platformen tilføjede eller formaliserede moduler som mod_proxy_fcgi, mod_proxy_scgi, mod_proxy_express, mod_proxy_html, mod_proxy_http2, mod_proxy_hcheck, mod_proxy_uwsgi og mod_proxy_wstunnel. Det fremgår også, at ProxyPass ved administration af et stort antal regler konfigureres mest effektivt i Location- eller LocationMatch-blokke, hvilket giver en markant performancefordel sammenlignet med den traditionelle syntaks med to parametre.

Det betyder ikke, at ældre proxy-stanzas automatisk er forkerte. Det betyder derimod, at mange miljøer nu indeholder flere generationer af beslutninger, som hver især var forståelige: en rewrite-workaround fra år tilbage, en senere regel til cookie-mapping, et trin til omskrivning af HTML fra en backend og protokolspecifikke proxy-moduler, der blev tilføjet længe efter, at den oprindelige vhost blev skrevet. Når den aktuelle liste over sårbarheder omfatter fejl, der udtrykkeligt involverer backends, som ikke er tillid til, eller som er ondsindede, giver det bedre mening at gennemgå disse dele samlet end fortsat at behandle dem som separate, afsluttede valg.

Det samme gælder .htaccess og håndteringen af klientidentitet. Apache 2.4 introducerede AllowOverrideList, som giver strammere kontrol med, hvad .htaccess kan gøre, samt mod_remoteip, som erstatter den tilsyneladende klient-IP og værtsnavnet på baggrund af headers fra proxies eller load balancers. Det er nyttige kontroller, men kun hvis tillidsmodellen omkring dem er eksplicit. Teams bør vide, hvilke mapper der stadig afhænger af lokale overrides, hvilke requests der bygger på videresendt klientidentitet, og hvor disse antagelser er dokumenteret i konfigurationen frem for kun at eksistere som institutionel hukommelse.

Sådan ser en nyttig revision faktisk ud

En værdifuld Apache-revision efter 2.4.68 er ikke en diffus best practices-øvelse. Det er en afgrænset teknisk gennemgang med klare driftsmæssige resultater. Begynd med at kortlægge de indlæste moduler, den aktive MPM og de proxy-backends, der reelt er i brug. Kortlæg derefter behandlingskæden for hver offentlig sti: direkte levering, reverse proxy, HTTP/2-backend, FastCGI, UWSGI, WebSocket-tunnel eller balancer. Gennemgå al brug af mod_proxy_html, ProxyPassReverseCookie*-direktiver og ældre syntaks til adgangskontrol. Overvej igen, om en bred AllowOverride stadig er berettiget, eller om AllowOverrideList kan indsnævre, hvad lokale .htaccess-forfattere må ændre.

Test samtidig opgraderingen i staging med de problematiske scenarier, der typisk udløser overraskelser i produktion: HTTP/2-edge cases, backendfejl, ældre PATH_INFO-adfærd og auth-flows, der er videreført fra tidligere udgivelser. Apaches udgivelsesmeddelelse tilføjer endnu en kontrol, som let overses under en forhastet opgradering: Hvis du vil køre en threaded MPM ud over prefork, skal samtlige moduler og afhængige biblioteker være thread-safe. Det er ikke glamourøst arbejde, men det er præcis den type arbejde, der forhindrer weekender med rollbacks.

Hvis du ønsker hjælp udefra, er dette tidspunktet for en afgrænset Apache- og edge-revision – ikke et infrastrukturprojekt uden klar afslutning. Greg kan hjælpe med at omsætte udgivelsen til konkrete opgaver: identificere de relevante moduler og proxy-stier, gennemgå nedarvning i auth og .htaccess, teste HTTP/2- og backendadfærd i staging, patche eller opgradere sikkert og fjerne de ældre konfigurationsmønstre, som bliver ved med at skabe regressioner, der kunne være undgået. Apache 2.4.68 er anledningen. Forretningsværdien opstår, når anledningen bruges til at forenkle miljøet, mens dokumentationen stadig ligger lige foran jer.

Relateret indhold på GrN.dk

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

Book en Apache- og edge-revision – kontakt Greg.

Kilder

Sidst ændret

2026-08-23