Some config entities expose PHP code and callbacks and may be dangerous if a malicious user is able to create or edit config entities. I've found multiple config entities that store this kind of data, but there are likely more that can be exploited.
Some examples I've found by grepping schema files:
./core/modules/views/config/schema/views.argument_validator.schema.yml
views.argument_validator.php:
type: mapping
label: 'PHP Code'
mapping:
code:
type: string
label: 'PHP validate code'
^ Possible to write arbitrary PHP code?
./core/modules/rdf/config/schema/rdf.data_types.schema.yml
rdf_field_mapping:
...
datatype_callback:
type: mapping
label: 'Data type callback'
mapping:
callable:
type: string
label: 'Callable'
arguments:
type: mapping
label: 'Arguments'
mapping:
interaction_type:
type: string
label: 'Interaction type'
mapping_type:
Also, potentially:
./core/config/schema/core.data_types.schema.yml
./core/modules/options/config/schema/options.schema.yml
field.field.*yml (maybe not defined in schema?)
Add validation constraints or otherwise control access to dangerous config entity values in core.
Create a plan, write a patch.
None.
TBD.
TBD.
TBD.
Needs work
10.1 ✨
Last updated
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
Used to track the progress of issues reviewed by the Drupal Needs Review Queue Initiative.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.
Think if we remove the schema we will need a post_update hook to remove it from views also. Then that hook would need a simple test case.