Een PHP-beveiligingspatch wordt in een container doorgaans geleverd via een opnieuw gebouwde image. Die image downloaden en in gebruik nemen zijn afzonderlijke stappen. Je updateplan moet ook de database en persistente bestanden beschermen die blijven bestaan nadat de container is verwijderd.
Maak een back-up van de applicatiegegevens, de database indien van toepassing en de configuratie voordat je de image wijzigt. Haal een ondersteunde, gepatchte release op, maak de service opnieuw aan, controleer de vervangende container en test de belangrijkste gebruikershandeling voordat je de update als voltooid registreert.
1. Leg de huidige implementatie vast
Controleer met docker compose ps de projectmap en servicenamen. Noteer de huidige imagetags en image-ID's met docker compose images, evenals de locaties van persistente volumes en databasegegevens. Bewaar een beveiligde kopie van de Compose-configuratie zonder geheimen in gedeelde logboeken bloot te leggen.
Controleer in de releaseopmerkingen van de doelimage of deze de PHP-fix bevat. Een tag met de naam latest bewijst niet dat een bepaalde patch erin zit. Als je een digest vastzet, moet deze worden gewijzigd in de geverifieerde vervangende digest.
2. Maak een consistente back-up
Gebruik de gedocumenteerde back-upmethode van de applicatie. Bewaar de configuratie, bestanden en een databaseback-up van een consistent herstelpunt. Zorg zo nodig voor een gecoördineerde onderbreking van schrijfbewerkingen of schakel de onderhoudsmodus in. Een kopie van de bestanden van een actieve database is niet altijd een geldig alternatief voor een databaseback-up.
Bewaar de herstelkopie buiten het bereik van schrijfhandelingen van de applicatie en zorg dat je weet hoe je deze terugzet. Bewaar de eerdere configuratie en imageverwijzing, maar houd er rekening mee dat je een oude, kwetsbare image niet zomaar weer rechtstreeks op het openbare internet moet zetten.
3. Haal de gewenste service op en maak deze opnieuw aan
Werk bij een image die door de maintainer is gepubliceerd de imageverwijzing van de service bij naar een compatibele, vaste release en gebruik vervolgens dit voorbeeld vanuit de juiste projectmap. Vervang app door de naam van de PHP-applicatieservice:
docker compose pull app
docker compose up -d --no-deps app
docker compose ps
docker compose exec -T app php -vDocker documenteert dat pull images downloadt zonder containers te starten; up past wijzigingen aan images of configuratie toe door containers opnieuw aan te maken. Hier beperkt --no-deps de wijziging tot de geselecteerde service. Gebruik dit alleen wanneer afhankelijke services gezond en compatibel zijn.
Werk bij aangepaste builds de relevante PHP-basis of pakketten bij, bouw opnieuw via je gebruikelijke buildpijplijn en implementeer de resulterende image. Herhaal dit voor workers die die runtime gebruiken. Pas geen tijdelijke container-shell aan in de veronderstelling dat de oplossing behouden blijft wanneer de container opnieuw wordt aangemaakt.
4. Valideer de applicatie voordat je de toegang herstelt
Controleer lokaal de logs op opstartfouten zonder tokens of privépadnamen te delen. Bevestig de web-runtime en test vervolgens het inloggen, bladeren door bestanden, een kleine upload en een achtergrondtaak. Controleer of de volumepaden en eigendomsrechten nog overeenkomen met de beoogde inrichting.
Als de openbare toegang was beperkt, schakel die dan pas weer in nadat de versie- en functionaliteitscontroles zijn geslaagd. Een groene containerstatus op zichzelf bewijst niet dat uploads of achtergrondtaken werken.
5. Herstel zorgvuldig als de validatie mislukt
Houd de service geïsoleerd tijdens het onderzoek. Herstel applicatiebestanden en de databasestatus samen als de migratieregels van de app dit vereisen; alleen de image wijzigen kan onveilig zijn na een schema-upgrade. Gebruik docker compose down -v niet als snelle oplossing voor problemen, want dit kan benoemde volumes verwijderen.
Houd voor ZimaCube 2-gebruikers de updategegevens gescheiden van je bulkbestanden en bewaar onafhankelijke back-ups. Een update is pas geslaagd als je een bekende runtime hebt, de applicatiefuncties werken en je nog steeds kunt uitleggen hoe je kunt herstellen.
Bekijk ZimaCube 2 persoonlijke cloud-NAS voor thuis voor je privéopslag en zelfgehoste applicatieomgeving. De softwarebeveiliging hangt af van de geïnstalleerde services, hun configuratie en geverifieerde updates.
Ga verder met de PHP-beveiligingsreeks
Bronnen en reikwijdte
Gecontroleerd op 22 oktober 2026. Implementatieadvies moet worden afgestemd op de documentatie van je applicatie en leverancier; deze artikelen tonen geen productgebonden blootstelling aan.
Ondersteuning & Tips
Meer om te lezen

Geheugen- en runtimevereisten controleren voordat je LFM2.5-24B-A2B uitvoert
Controleer de gewichtsindeling van LFM2.5-24B-A2B, het geheugengebruik, de runtimeversies, de context en de compatibiliteit met tools voordat je het model op een homeserver probeert...

Granite Speech 5.0 testen met Engelse audiobestanden die op je NAS zijn opgeslagen
Test Granite Speech 5.0 met een korte Engelse opname van je NAS. Controleer de checkpointrevisie, runtime, samplefrequentie, transcriptiekwaliteit en uitvoerverwerking.

Bestanden en machtigingen voorbereiden voor een Claude Duet-workflow
Bereid een Claude Duet-taak voor met geselecteerde bestanden, afgebakende gekoppelde accounts, afzonderlijke concepten, controleerbare resultaten en een duidelijk plan om de verbinding te verwijderen.

