# Patcha PHP i Kubernetes > Patcha Kubernetes PHP-image efter PHP2Shell: hitta sårbara pods, bygg om images, rulla ut alla workloads och styrk läget per pod med belägg. Källa: https://phpsos.de/sv/server/kubernetes/ Aktualitet: 2026-10-25 Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6 **Kort sagt:** I Kubernetes sitter PHP i container-imagen, inte i klustret. Efter PHP2Shell måste ni bygga om varje Kubernetes PHP-image med åtgärdad PHP-version, rulla ut alla berörda workloads på nytt och därefter kontrollera läget i varje körande pod. En uppdaterad bas-image i registret ändrar ingenting för körande pods. ## Varför klustret självt inte patchar Kubernetes förvaltar containrar men bryr sig inte om programvaran i dem. Varje pod körs med den image den startades från tills den ersätts. Den som driver PHP-applikationer i klustret bär därför ansvaret för imagerna, även om klustret körs som en hanterad tjänst hos en molnleverantör. Leverantören underhåller typiskt kontrollplanet och noderna, inte kundernas images. PHP2Shell omfattar CVE-2026-109618 och CVE-2026-109619, vardera med CVSS v4.0 9,2. Bland annat PHP-FPM, Apache med mod_php och FrankenPHP berörs, alltså de vanliga driftlägena i PHP-images. Åtgärdade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. ## Inventering: vilken Kubernetes PHP-image körs var? Börja med en lista över alla images i klustret. Följande kommandon läser bara. Namn på namespaces, deployments och containrar är exempel. ```bash # Alla images för alla pods, grupperade kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' # Faktiskt körande image-digest per container kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}' # PHP-version i en körande pod kubectl exec -n shop deploy/web -c php -- php -v ``` Tänk förutom på deployments även på StatefulSets, DaemonSets, CronJobs och init-containrar. I större kluster hjälper image-skannrar som söker igenom images efter kända CVE:er. För distributionspaket inuti imagen gäller som överallt: en backport kan lämna versionsnumret oförändrat, då räknas paketets ändringslogg. ## Bygg om images Uppdatera först bas-imagen. Använder ni officiella PHP-images väljer ni en variant med åtgärdad PHP-version. Bygg sedan er egen image på nytt, utan att ta över det gamla baslagret från cachen. ```bash # Exempel: bygg om imagen, hämta bas-imagen aktivt på nytt docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 . # Kontrollera PHP-versionen i den nya imagen före utrullningen docker run --rm registry.example.com/shop/web:2026-10-25 php -v ``` Förlita er inte på taggar som `latest` eller en blott huvudversion. Referera i manifestet helst till den nya imagens digest, så att det är entydigt vilken version som rullas ut. Sker driftsättningen via GitOps eller Helm ändrar ni imagen där, så att läget inte återställs vid nästa avstämning. ## Utrullning och kontroll En ny utrullning ersätter alla pods i en workload stegvis. Därefter kontrollerar ni läget i de körande podarna. Först då är patchen verksam, eftersom nya filer bara hjälper om gamla PHP-processer inte längre körs. ```bash # Utrullning med ny image (namn som exempel) kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256: kubectl -n shop rollout status deploy/web # Kontroll: alla pods omstartade, ny digest aktiv? kubectl -n shop get pods -o wide kubectl -n shop exec deploy/web -c php -- php -v ``` Har imagen pushats på nytt under samma tagg utlöser `kubectl rollout restart` en omstart; pods hämtar dock imagen på nytt bara om `imagePullPolicy` föreskriver det. Säkrare är bytet till en ny digest. > **Viktigt:** > Säkra loggar innan ni ersätter pods. Med den gamla podden försvinner också dess lokala loggar. Spara webbserver- och applikationsloggar från och med den 20 oktober 2026, helst i en central loggplattform. ## Tillfälliga åtgärder i klustret Om det för er PHP-version ännu inte finns någon åtgärdad image rekommenderar php.net tillfälliga åtgärder utan fullständigt skydd. I klustret sätter ni minnesgränser via containrarnas resursgränser, som bygger på cgroups. Det motsvarar rekommendationen att begränsa minnet via container eller cgroups och inte via `RLIMIT_AS` eller `RLIMIT_DATA`. ```ini ; php.ini eller FPM-pool i imagen, t.ex. inkopplad via ConfigMap session.upload_progress.enabled = 0 post_max_size = 8M upload_max_filesize = 6M ``` Med uppladdningsfunktion anger php.net `post_max_size = 32M`. På PHP 8.5 tillkommer `fatal_error_backtraces=0`. Efter ändring av konfigurationen behövs en ny utrullning. Som komplement begränsar NetworkPolicies utgående anslutningar från PHP-podarna, och en Ingress med skyddsregler kan försvåra angreppsförsök. Regler enbart baserade på förfrågningsdata räcker enligt Cloudflare dock inte. ## Ställ upp bättre långsiktigt Planera regelbundna automatiska ombyggen av alla PHP-images, en image-kontroll i bygg-kedjan och policyer som bara släpper igenom signerade eller kontrollerade images. Om PHP-containrar körs med användare utan root-rättigheter och skrivskyddat filsystem minskar skadan vid ett lyckat angrepp. Anvisningar för enskilda containrar finns under [Patcha PHP i Docker-containrar](https://phpsos.de/sv/php2shell/docker-container-patchen/), för FrankenPHP under [Säkra FrankenPHP](https://phpsos.de/sv/server/frankenphp/). I många kluster körs PHP-applikationer inte ensamma. Ofta finns sidecar-containrar för loggning eller mätvärden, hjälp-images för databasmigreringar och jobb som bara startar på natten. Även images från tredje part, till exempel för en wiki, ett övervakningsgränssnitt eller ett ärendesystem, kan innehålla PHP utan att det syns i namnet. Kontrollera därför inte bara era egna applikationer utan varje image i klustret. För främmande images gäller: vänta på en uppdaterad version från tillverkaren, kontrollera dennes uppgifter om den inbyggda PHP-versionen och begränsa nåbarheten tills den finns. Körs ett sådant system bara internt sänker det risken men ersätter inte uppdateringen. ## Hur hjälper PHP SOS konkret? - Vi kartlägger alla workloads med PHP, deras images och digests och kontrollerar PHP-versionen i körande pods. - Via [PHP-patchtjänsten](https://phpsos.de/sv/leistungen/php-patch-service/) bygger vi om images, rullar ut dem och dokumenterar läget per workload. - Vi säkrar loggar före bytet och kontrollerar med avseende på spår av ett angrepp. - Med [säkerhetsövervakning](https://phpsos.de/sv/leistungen/security-monitoring/) och automatiserade ombyggen ser vi till att nästa patch kommer ut i klustret snabbare. ## Vanliga frågor **Räcker det att uppdatera bas-imagen i registret?** Nej. Körande pods fortsätter använda den image de startades med. Först en ny utrullning med den ombyggda imagen ersätter podarna. Kontrollera därefter PHP-versionen i varje körande pod. **Varför referera images via digest?** En tagg kan peka på olika image-versioner beroende på när den hämtades. En digest anger exakt en version. Då vet ni säkert vilken kod som körs i vilken pod, och utrullningar blir spårbara. **Hur är det med CronJobs och init-containrar?** Även de kan innehålla PHP och hör till inventeringen. CronJobs startar nya pods ur sin mall vid varje körning; uppdatera därför imagen i mallen. Init-containrar körs när varje pod startar. **Skyddar en NetworkPolicy mot PHP2Shell?** Den stänger inte sårbarheten men kan begränsa skadan. Den som begränsar utgående anslutningar från PHP-pods försvårar nedladdning av skadlig kod och förflyttning i sidled i klustret. ## Källor - [php.net: säkerhetsmeddelanden](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [BSI](https://www.bsi.bund.de/)