Hello Arsan,
Thank you very much for your consideration to my inquiries.
If an attacker exploits a vulnerability in an application, the impact could be reduced if the affected execution context is not authorized to perform sensitive operations.
This sounds great. When I hear something like that it reminds me of Denojs (Nodejs competitor). Although the mechanism for protecting against unintended capabilities are different (flag passing on binary run vs code declaration), the idea is the same.
In the case of PHP2SHELL, I have read that one of the vulnerabilities is tied to an invalid memory access, a use after free. Well in those cases, I’m not sure that this Effect mechanism could solve it because these vulnerabilities causes Undefined Behavior, and there is no way to assert that the effect mechanism will handle it. Although, the idea is still very interesting. Maybe some more exploration toward it could result in something brilliant.
One analogy I have in mind is the permission model used by mobile operating systems. An application may request internet access, camera access, or filesystem access, but the operating system determines which permissions it actually receives. Some applications may have a permission while others do not.
Nice. Klever idea. Although in this case, it wouldn’t be necessary as PHP runtimes (php-cli, php-fpm, etc) are the one that defines the contract for PHP functionalities (through the inclusion of shared libraries/extensions enabled per runtime). However, the effect would be perfect in the contact of an application extension: you have CRM/ERP PHP app with many capabilities that enable you to access to different features (accounting, finance, customers, system files, etc.). These are the things I work on with a Modular CMS/CRM/ERP based on Symfony that I’m creating, and just by loading some Composer Packages everything is wired through automatic dependency injection + Custom Attributes.
The same distinction could apply to filesystem access: an effect could declare that a function reads files, while a runtime policy determines which paths are permitted.
I am open to whether parameterized effects should contain literal constraints, reference named policies, or simply describe the operation while leaving authorization to a separate mechanism.
Consider a function exposed through an HTTP endpoint whose responsibility is only to perform a calculation. Ideally, that function should not be able to make arbitrary API requests, read arbitrary files, or execute system commands merely because PHP currently allows those operations. Its permitted effects and runtime authority should reflect what it actually needs to do.
The broader goal is to explore whether PHP could move towards a model where potentially sensitive operations are both visible in code and constrained by enforceable permissions, rather than relying exclusively on developers to remember every possible attack path.
Ok I like those idea 
. Sounds very good, thank you for bringing them into the table. I’m enjoying this talk a lot 
.
What about testing the idea right away? Maybe by creating a PHP extension? Maybe at first it is possible to start with PHP Attributes… It is true that the syntax of an attribute is not the same as the syntax proposed, but It would be great to see if the idea can work, as it would be very valuable for the PHP community. I think a PHP extension through the Rinit hook (or at most Minit) can ensure to check the code are runtime and force these constraints on each request?
A positive point forward using extension and PHP Attribute is that there is no need to update the PHP parser: syntax is still the same. And after that, if a third party extension work, you can easily integrate it to PHP. Also, with something like that, it is easier to pass it though Unit testing and maybe static analysers by doing some klever tricks.
Also a good point for a third part extension is that if everything works and is well defined, I think php-internal developers will appreciate that job already done, and it would also be easier for them to include it in PHP by default. If you do so contact me, I’m interested in your proposal 
.
Great job for your efforts,
Kind regards,
David Maye
On Oct 26, 2026 2:50 PM, Arsan Gamal arsan.gamal@gmail.com wrote:
Hello David,
Thank you for taking the time to read the proposal and share your questions. I appreciate the feedback, and I think these are important points to clarify.
1. Effects for process execution
I agree that invoking native binaries should not be encouraged as a default approach when an API or shared library is more appropriate. My intention is not to promote process execution, but to make potentially dangerous operations explicit and controllable.
The main motivation behind this idea is to explore whether PHP could provide stronger protection against unintended or unauthorized operations, including attacks such as PHP2Shell. If an attacker exploits a vulnerability in an application, the impact could be reduced if the affected execution context is not authorized to perform sensitive operations.
One analogy I have in mind is the permission model used by mobile operating systems. An application may request internet access, camera access, or filesystem access, but the operating system determines which permissions it actually receives. Some applications may have a permission while others do not.
Similarly, a PHP application or execution context could be granted specific capabilities, while sensitive operations would be denied when the required authorization is absent. Process execution is simply one potential use case, and perhaps a useful starting point because of its security implications.
2. Parameterized effects and configurable values
I agree with your point about API domains and environment-specific configuration. Hardcoding a hostname in an effect declaration would create unnecessary coupling if the endpoint changes between environments or needs to be updated.
I would not want effect declarations to replace configuration or require a language-level versioning change whenever a string value changes.
Instead, parameterized effects could describe constraints or categories of operations, with the actual values supplied through configuration or checked against runtime policy. For example, an effect could indicate that a function may perform network requests, while the permitted hosts are determined by the application’s configuration and enforced at runtime.
The same distinction could apply to filesystem access: an effect could declare that a function reads files, while a runtime policy determines which paths are permitted.
I am open to whether parameterized effects should contain literal constraints, reference named policies, or simply describe the operation while leaving authorization to a separate mechanism.
3. Static analysis versus runtime enforcement
I agree that static analysis cannot reliably determine every operation in a dynamic language such as PHP, particularly when behavior depends on runtime input, dynamic calls, or native extensions. I do not expect PHPStan or Psalm to replace runtime security enforcement.
However, I think static analysis could still provide value by identifying operations that contradict declared effects.
For example, if a function declares that it only performs calculations, a static analyzer could flag direct or indirect calls to known filesystem-reading functions, such as glob() or file_get_contents(), where those calls are identifiable. Similar checks could be applied to network and process-execution APIs.
This would not be a complete security guarantee. Dynamic dispatch, indirect calls, and native extensions would introduce limitations. Runtime enforcement would therefore be necessary for security-sensitive operations, with the PHP engine or another trusted runtime mechanism checking whether the active execution context has the required authority.
Consider a function exposed through an HTTP endpoint whose responsibility is only to perform a calculation. Ideally, that function should not be able to make arbitrary API requests, read arbitrary files, or execute system commands merely because PHP currently allows those operations. Its permitted effects and runtime authority should reflect what it actually needs to do.
The broader goal is to explore whether PHP could move towards a model where potentially sensitive operations are both visible in code and constrained by enforceable permissions, rather than relying exclusively on developers to remember every possible attack path.
I realize this raises substantial questions around backward compatibility, the existing extension ecosystem, and the boundary between language semantics and runtime security. I do not have all the answers yet, and feedback like yours is helpful in determining the right direction and scope.
Thank you again for engaging with the proposal.
Sincerely,
Arsan Gamal
Sent from Gmail
On Mon, 26 Oct 2026 at 4:20 PM David Maye <david.maye@seigisoft.com> wrote:
Hello Arsan. It sounds very interesting.
However I have some questions:
-
Use of effect for binaries: I’m not used to the idea of using PHP to invoke a Binary. Most of the time it tries to invoke an API or a shared library or something similar. Is it a good idea to encourage calling native binaries? (I’m sure some people do it. But adding such as a green check of “you can do it”, seems a little of).
-
The use of effect for API call: It is interesting. But what if you want to update an API endpoint/domain? You would have to manually change it in the code. Is a SemVer-like (semantic versioning) change necessary for a string data? As far a I know people get these value from an .env file or something ? (The filesystem.read you gave seems more appropriate.
-
I’m not sure that any static analyser would be able to check it. Because these kind of checks are to be done in runtime, right? Does PHPStan or Psalm for instance do test in runtime? It seems that it would be a responsibility for the PHP engine/runtime?
What do you think?
Kind regards,
David Maye
On Oct 25, 2026 2:38 PM, Arsan Gamal <arsan.gamal@gmail.com> wrote:
Hello PHP Internals,
I would like to propose an idea for discussion regarding the introduction of effect declarations in PHP, with a particular focus on making function behavior more explicit and improving the security and auditability of sensitive operations.
Currently, PHP function signatures describe parameters and return values but do not indicate which external operations a function may perform. A function may execute operating-system commands, access the filesystem, or make network requests through its implementation or dependencies without these operations being visible in its signature.
I believe an effect system could help address this limitation by allowing functions to declare the operations they may perform. These declarations could support static analysis, contract checking, code auditing, and potentially stronger security controls.
Proposed syntax
As an initial proposal, effects could be declared alongside a function’s return type:
function generateReport(string $input): string
effects [process.execute]
{
// Implementation
}
Effects could also accept parameters to describe the scope of an operation:
function generateReport(string $input): string
effects [
process.execute(
commands: ['/usr/bin/report-renderer']
)
]
{
// Implementation
}
In this example, the effect declaration indicates that the function may execute a process, with the declared contract restricting the intended executable to the report renderer.
The same concept could be extended to other operations:
function readConfiguration(): string
effects [
filesystem.read(
paths: ['/etc/myapp/config.json']
)
]
{
// Implementation
}
function fetchReport(string $url): string
effects [
network.request(
hosts: ['[api.example.com](http://api.example.com)']
)
]
{
// Implementation
}
These examples are illustrative and are not intended to prescribe the final grammar. The syntax, supported effect types, parameter formats, and enforcement rules would need to be discussed and evaluated.
Effect checking and security
I envision effects serving as explicit contracts describing the operations a function may perform. A static analyzer or compiler could check whether implementations and their dependencies respect these declarations, identify undeclared effects, and make sensitive operations more visible during code review.
Parameterized effects could provide additional information about the intended scope of an operation. For example, a function declaring a process-execution effect restricted to a particular executable could be checked for attempts to execute other programs.
I would also like to explore how this proposal could complement a capability-based security model. Effects and capabilities would have separate responsibilities: effects would describe the operations and constraints associated with a function, while capabilities would determine which operations are authorized at runtime.
For example, an application could grant a request handler permission to execute a specific binary with defined argument constraints and resource limits. The runtime would enforce that permission when a process is created, independently of the function’s effect declaration.
This distinction is important because declaring an effect should not automatically grant authority to perform the operation. Runtime enforcement would remain necessary for security-sensitive operations, even if static effect checking were available.
Scope and open questions
I recognize that PHP’s dynamic features, backward-compatibility requirements, and native extension ecosystem present significant design and implementation challenges. Some questions that would need further exploration include:
-
Whether effects should be explicitly declared, inferred, or support both approaches.
-
How effects should propagate through function calls, closures, dynamic calls, and third-party dependencies.
-
How parameterized effects should be represented and validated.
-
Whether effect contracts should be enforced by the PHP engine, external static analysis tools, or a combination of both.
-
How effects could integrate with runtime capabilities and existing APIs.
-
How strict enforcement could be introduced without breaking existing PHP applications.
The proposal would not, by itself, prevent vulnerabilities within the PHP engine or native extensions. Any runtime security guarantees would depend on the coverage and correctness of the enforcement mechanisms.
I have started drafting an RFC exploring these ideas, using process execution as an initial use case. I would welcome feedback on whether effect declarations and parameterized effects would be a worthwhile direction for PHP, whether the proposed syntax fits the language, and what scope would be appropriate for an initial RFC.
If there is interest, I would be happy to share the draft and work on a proof of concept.
Thank you for your time and consideration.
Respectfully yours,
Arsan Gamal
Senior Software Engineer