# Konfigurér php.ini sikkert > Konfigurér php.ini sikkert: indstillinger for fejl, sessioner, uploads og hukommelse samt PHP2Shell-overgangsforanstaltningerne fra php.net til kopiering. Kilde: https://phpsos.de/da/ratgeber/php-ini-sicher-konfigurieren/ Status: 25.10.2026 Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **Kort sagt:** For php.ini-sikkerheden tæller først og fremmest fire områder: ingen fejlmeddelelser udadtil, sikre session-cookies, begrænsede uploads og spærrede værdier, som applikationer ikke kan overskrive. Efter PHP2Shell kommer php.nets overgangsforanstaltninger til, især `session.upload_progress.enabled=0`. En sikker konfiguration erstatter dog aldrig opdateringen. ## Hvorfor php.ini igen er i fokus efter PHP2Shell php.ini er PHP's centrale konfigurationsfil. På mange servere blev den sat op én gang og derefter næsten ikke rørt. Med PHP2Shell har det ændret sig: For de to sårbarheder CVE-2026-109618 og CVE-2026-109619 nævner php.net overgangsforanstaltninger, som sætter ind netop her. Selve sårbarhederne sidder i PHP-fortolkeren. De er rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35, offentliggjort den 21.10.2026. En god konfiguration hjælper alligevel på to måder: Den kan gøre udnyttelsen vanskeligere, og den begrænser skaden, hvis noget alligevel slipper igennem. Mange driftsansvarlige ved desuden ikke præcis, hvilke indstillinger der gælder på deres server. Det er det første skridt. ## Hvilken php.ini gælder på jeres server? PHP kan afhængigt af driftsformen læse forskellige konfigurationsfiler. Kommandolinjen, PHP-FPM og Apache med mod_php har under Debian og Ubuntu f.eks. hver deres mapper under `/etc/php//`. Den, der kun ændrer CLI-filen, ændrer intet ved websitet. ```bash # Kommandolinjens konfigurationsfiler php --ini # Konfiguration af PHP-FPM (tilpas versionsnummeret) php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir" # Kontrollér enkeltværdier for PHP-FPM php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) " ``` Desuden kan værdier stå i FPM-poolen, i Apache-konfigurationen, i `.htaccess` (kun mod_php) eller i `.user.ini` (FPM og CGI). Hvilken version der faktisk kører på serveren, og om en backport er indeholdt, afklarer indlægget [Kontrollér PHP-version og patchstatus korrekt](https://phpsos.de/da/php2shell/php-version-pruefen/). ## Grundindstillinger for mere php.ini-sikkerhed De følgende værdier er fornuftige for de fleste produktionsservere. Kontrollér før brug i et testmiljø, om jeres applikation klarer alle værdierne. ```ini ; Ingen versionsangivelse i HTTP-headeren expose_php = Off ; Log fejl, men vis dem aldrig i browseren display_errors = Off display_startup_errors = Off log_errors = On error_log = /var/log/php/error.log ; Indbind ingen filer fra eksterne adresser allow_url_include = Off ; lad kun allow_url_fopen være aktiv, hvis applikationen har brug for det allow_url_fopen = Off ; Sessioner: strikse, kun via HTTPS, ikke læsbare via JavaScript session.use_strict_mode = 1 session.use_only_cookies = 1 session.cookie_secure = 1 session.cookie_httponly = 1 session.cookie_samesite = Lax ; Begræns køretid og input max_execution_time = 30 max_input_time = 60 max_input_vars = 1000 ``` `allow_url_fopen` har nogle applikationer brug for til opdateringer eller grænseflader. Slå det kun fra, hvis I har kontrolleret det først. Funktioner, der udfører systemkommandoer, kan desuden spærres; hvordan det lykkes uden bivirkninger, forklarer vejledningen [Brug disable_functions korrekt](https://phpsos.de/da/ratgeber/disable-functions/). ## Overgangsforanstaltninger fra php.net til PHP2Shell Hvis I ikke kan patche med det samme, nævner php.net flere indstillinger, der sænker risikoen. De er udtrykkeligt ikke en fuldstændig beskyttelse, men en bro til opdateringen. ```ini ; Slå session upload progress fra (også på grund af CVE-2026-115560) session.upload_progress.enabled = 0 ; Begræns forespørgselsstørrelsen: 8M uden uploads, 32M med uploads post_max_size = 8M upload_max_filesize = 6M ; Kun PHP 8.5: ingen backtraces ved alvorlige fejl fatal_error_backtraces = 0 ``` Dertil anbefaler php.net at sætte `memory_limit=-1` således, at applikationer ikke kan overskrive værdien, og i stedet trække hukommelsesgrænsen via container eller cgroup, ikke via `RLIMIT_AS` eller `RLIMIT_DATA`. Denne foranstaltning hører hjemme i FPM-poolen eller serverkonfigurationen og bør kombineres med en fungerende cgroup-grænse. Det fulde overblik finder I under [Akutforanstaltninger, hvis I endnu ikke kan patche](https://phpsos.de/da/php2shell/sofortmassnahmen-ohne-patch/). > **Vigtigt:** > `session.upload_progress.enabled=0` virker kun fra php.ini, FPM-pool eller serverkonfiguration. Sat via `ini_set()` eller `.user.ini` griber foranstaltningen ikke. Genstart derefter alle workere. ## Spær værdier mod overskrivning Mange applikationer sætter egne værdier, f.eks. for hukommelse eller uploads. Med `php_admin_value` og `php_admin_flag` fastlægger I indstillinger, så hverken `ini_set()` eller `.user.ini` kan ændre dem. I FPM-poolen ser det sådan ud: ```ini ; /etc/php/8.3/fpm/pool.d/meine-seite.conf (uddrag) php_admin_flag[display_errors] = off php_admin_flag[session.upload_progress.enabled] = off php_admin_value[memory_limit] = -1 php_admin_value[post_max_size] = 8M php_admin_value[upload_max_filesize] = 6M php_admin_value[error_log] = /var/log/php/meine-seite.error.log ``` Under Apache med mod_php gælder samme logik med `php_admin_value` og `php_admin_flag` i VirtualHost-konfigurationen. Genindlæs derefter tjenesten, og kontrollér den aktive værdi: ```bash sudo systemctl reload php8.3-fpm # Processernes starttidspunkt: Ligger det efter ændringen? ps -eo pid,lstart,cmd | grep "[p]hp-fpm" ``` Et reload genstarter PHP-FPM's workere. Efter en PHP-opdatering er der derimod brug for en fuldstændig genstart af alle PHP-processer, så ingen gammel proces kører videre i hukommelsen. Ved flere websites på en server kan en egen pool pr. website desuden betale sig, mere om det i vejledningen [open_basedir og isolation pr. website](https://phpsos.de/da/ratgeber/open-basedir/). ## Hyppige fejl og en kort tjekliste De fleste problemer med php.ini opstår ikke på grund af forkerte værdier, men på grund af værdier det forkerte sted. Typisk er den ændrede CLI-fil, mens websitet kører via PHP-FPM. Lige så ofte udebliver genstarten efter en ændring, eller et hostingpanel overskriver den egne indstilling ved næste lagring. En anden klassiker er synlige fejlmeddelelser på det live website. De afslører stier, databasenavne eller versioner og letter angribernes orientering. Netop efter en flytning eller en nyinstallation står `display_errors` ofte igen på `On`. Disse punkter bør I kontrollere efter hver ændring og efter hver PHP-opdatering: 1. Hvilken konfigurationsfil læser web-driftsformen, og indeholder den jeres værdier? 2. Er `display_errors` og `expose_php` slået fra, og kan fejlloggen skrives? 3. Står `session.upload_progress.enabled` på `0`, sat via php.ini eller pool? 4. Er upload- og forespørgselsstørrelser begrænset passende til applikationen? 5. Kører alle PHP-processer med et starttidspunkt efter den sidste ændring? Notér resultatet med dato. Så kan det senere dokumenteres, hvornår hvilken indstilling gjaldt. ## Hvordan hjælper PHP SOS konkret? - Vi finder ud af, hvilken konfiguration der faktisk er aktiv i hvilken driftsform. - Vi indfører en afstemt grundkonfiguration og PHP2Shell-overgangsforanstaltningerne, testet med jeres applikation. - Vi spærrer sikkerhedsrelevante værdier mod overskrivning og genstarter alle workere kontrolleret. - Vi dokumenterer indstillinger og kontrolresultat, så senere ændringer forbliver sporbare. Hvordan en varig sikring ser ud, beskriver ydelsen [Serverhærdning til PHP-webservere](https://phpsos.de/da/leistungen/server-haertung/). ## Ofte stillede spørgsmål **Hvilken php.ini bruger min webserver egentlig?** Det er ofte ikke den samme som på kommandolinjen. PHP-FPM, Apache med mod_php og CLI har som regel egne konfigurationsmapper. Kontrollér derfor den aktive fil via den pågældende driftsform, f.eks. med php-fpm -i eller en kortvarigt lagt kontrolfil. **Erstatter en sikker php.ini PHP-opdateringen?** Nej. Indstillingerne mindsker angrebsfladen og gør en udnyttelse vanskeligere, men lukker ingen sårbarhed i PHP-fortolkeren. Også php.nets overgangsforanstaltninger til PHP2Shell er udtrykkeligt ikke en fuldstændig beskyttelse. **Hvad er forskellen på php_value og php_admin_value?** Værdier sat med php_value kan applikationen ændre igen under kørslen. Værdier via php_admin_value i FPM-poolen eller i Apache-konfigurationen er derimod spærret for applikationen, også for ini_set() og .user.ini. **Skal jeg genstarte efter en ændring i php.ini?** Ja. PHP-FPM og Apache med mod_php læser konfigurationen kun ved start. Først efter en genstart eller reload af alle berørte tjenester gælder de nye værdier. ## Kilder - [php.net: Sikkerhedsmeddelelser](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) - [BSI IT-Grundschutz (det tyske forbundskontors grundbeskyttelse for IT)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)