Examples include disabling a vulnerable feature, restricting access to an endpoint, blocking a known attack pattern or isolating a service behind stronger network controls. The right measure depends on how the specific flaw can be reached.
A mitigation may interrupt legitimate traffic or leave other exploit paths open. A web application firewall rule that blocks one published payload is not necessarily protection against variations, and a configuration change may cover only one PHP handler while another remains exposed.
Temporary controls are especially useful when patch testing or a maintenance window delays the permanent fix. They should have a named owner, a documented reason and a removal condition so they do not silently become permanent substitutes for updates.
Follow the vendor's guidance for the exact vulnerability, test that the affected feature is truly restricted, and replace the mitigation with a verified patch as soon as practical.