---
title: "Wat is LSAPI? Uitleg en betekenis | Keurig Online"
description: "LSAPI (LiteSpeed Server API) is het protocol waarmee de webserver LiteSpeed PHP-verzoeken doorgeeft aan aparte PHP-processen."
canonical: https://www.keurigonline.nl/begrippenlijst/lsapi
last_modified: 2025-12-18
---

[Terug naar begrippenlijst](https://www.keurigonline.nl/begrippenlijst)

# LSAPI

LSAPI (LiteSpeed Server API) is het protocol waarmee de webserver LiteSpeed PHP-verzoeken doorgeeft aan aparte PHP-processen.

Actueel: [CVE-2026-109618 en -109619: de technische deepdive](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive)

LSAPI (LiteSpeed Server API) is het protocol waarmee de webserver LiteSpeed verzoeken voor PHP-scripts doorgeeft aan PHP. PHP draait daarbij als een eigen programma, lsphp, en dus net als bij PHP-FPM los van de webserver. Volgens de handleiding van PHP lijkt het protocol op FastCGI, maar werkt het efficiënter.

LiteSpeed kan lsphp op meerdere manieren starten. In de ProcessGroup-modus start de webserver één PHP-ouderproces dat blijft draaien en voor nieuwe verzoeken kindprocessen afsplitst, in plaats van telkens een nieuw proces op te starten. Dat scheelt opstarttijd en maakt een gedeelde opcodecache mogelijk, ook op shared hosting. Met LSAPI\_CHILDREN bepaalt de beheerder hoeveel kindprocessen er tegelijk mogen draaien.

LSAPI werkt niet alleen in LiteSpeed. CloudLinux maakt mod\_lsapi, een module die dezelfde techniek in Apache inbouwt als alternatief voor mod\_php, suPHP en PHP-FPM. Instellingen in .htaccess, zoals php\_value memory\_limit 256M, blijven onder LSAPI gewoon werken.

Op de shared hosting van KeurigOnline (cl01 tot en met cl09) draait PHP via de PHP-koppeling van LiteSpeed, binnen CloudLinux CageFS. Een eigen .user.ini leest lsphp alleen als de beheerder dat heeft aangezet. Je PHP-waarden pas je daar daarom het makkelijkst aan in DirectAdmin, via Extra Features, Select PHP Version en Options.

## Geschiedenis

LiteSpeed Technologies werd in 2002 opgericht door een team rond George Wang, en LiteSpeed Web Server verscheen op 1 juli 2003 ([Wikipedia](https://en.wikipedia.org/wiki/LiteSpeed_Web_Server)). Gebruikers moesten PHP lange tijd zelf patchen om LSAPI te gebruiken. In maart 2008 vroeg Wang daarom of de LiteSpeed-SAPI in de standaardversie van PHP kon ([PHP internals](https://externals.io/message/36453)).

Belangrijke mijlpalen:

- **2003:** LiteSpeed Web Server verschijnt
- **30 juni 2009:** PHP 5.3.0 neemt de LiteSpeed-SAPI op in de standaardbroncode ([changelog](https://www.php.net/ChangeLog-5.php#5.3.0))
- **Februari 2019:** cPanel levert een lichte versie van mod\_lsapi van CloudLinux mee in EasyApache 4 ([cPanel](https://www.cpanel.net/blog/products/easyapache-4-and-mod-lsapi/))

## Bronnen

1. **PHP.net** - [LiteSpeed Web Server/OpenLiteSpeed Web Server on Unix systems](https://www.php.net/manual/en/install.unix.litespeed.php)
2. **LiteSpeed Technologies** - [PHP LSAPI Overview](https://www.litespeedtech.com/open-source/litespeed-sapi/php)
3. **LiteSpeed Documentation** - [LSPHP Options (ProcessGroup, LSAPI\_CHILDREN, .user.ini)](https://docs.litespeedtech.com/lsws/extapp/php/configuration/options/)
4. **CloudLinux** - [mod\_lsapi PRO](https://docs.cloudlinux.com/cloudlinuxos/cloudlinux_os_components/#mod-lsapi)
5. **cPanel (2019)** - [EasyApache 4 and mod\_lsapi](https://www.cpanel.net/blog/products/easyapache-4-and-mod-lsapi/)

## Gerelateerde artikelen

Beveiliging 22 okt 2026

[CVE-2026-109618 en -109619: de technische deepdive](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive)

- **PHP-FPM** sluit de child af op datzelfde startup-pad ("PHP-FPM exits the child on this startup failure path instead"). Het PHP-advies houdt FPM na de startup nog wel voor vatbaar, maar er is geen volledige FPM-exploit voor CVE-2026-109618. Voor CVE-2026-109619 is wel een gevalideerde FPM-keten: een sessie-operatie in de applicatie die `BG(unserialize)` publiceert, gevolgd door upload progress op een later request naar dezelfde worker.
- **LiteSpeed (LSAPI)** behandelt de analyse niet. lsphp draait ook als aparte, langlevende processen die meerdere requests afhandelen, dus de voorwaarde "twee requests op dezelfde worker" kan daar evengoed gelden. Wij hebben LSAPI daarom behandeld als FPM.

Voor beide CVE's geldt dat de staat met de worker sterft: "When a worker dies, the stale state dies with it." Keep-alive helpt een aanvaller alleen als de frontend de verbinding aan dezelfde worker koppelt, en dat is geen garantie.