Potential XSS vulnerability in colorbox and lazy load formatters

Hi @plopesc, how are we supposed to sanitize it exactly?

It looks like it could be anything in there, here is the code adding the attribute in the LazyLoad field formatter for example:

      $element[$delta] = [
        '#type' => 'container',
        '#attributes' => [
          'data-video-embed-field-lazy' => (string) $this->renderer->render($videos[$delta]),
          'class' => ['video-embed-field-lazy'],

DOMPurify (https://github.com/cure53/DOMPurify) could be used for this, but it would add a new dependency.

Shouldn't it be fixed on CKEditor side preferably?

It's true that this can be mitigated by not allowing the data-video-embed-field-modal in CKE config.
However, there are valid reasons to allow data-* attributes and they are not dangerous by themselves.

video_embed_field turns a safe attribute into dangerous markup so it should be this module's responsibility to ensure the markup is safe.

Looks like it would be a huge architectural change then, as the embed rendered code could have some valid javascript code in it.

What would be the best way to do that then? Load the rendered code using Ajax?

I see several ways to fix this:

• Sanitize the value of data-video-embed-field-modal with DOMPurify before using it. But if the embed can contain legitimate JS this would remove it.
• Insert the embed somewhere in the page (in a div tag with display:none; for example) and only have a selector in the data attribute.
• Render the embed in a drupalSettings variable and use this variable to generate the dialog.
• Load the embed with AJAX.

Thanks for the suggestions.

So one of these solutions will have to be implemented before we merge back the CKEditor plugins into the 3.x dev branch.

gaëlg → made their first commit to this issue’s fork.

Proposed Fix
Sanitize the data-* attribute values before injecting them into the DOM. Possible approaches:

• Use Drupal\Component\Utility\Html::escape() to sanitize the input.
• Strip unwanted HTML/JS before processing the attribute.
• Use data-* safely by ensuring values are treated as plain text, not HTML.

Next Steps

• Patch needed: A developer should submit a fix that properly escapes the data-* attributes.
• Testing: Verify the fix prevents XSS while maintaining functionality.
• Security advisory: Since this is public, a SA may be needed if the risk is deemed high enough.

This seems to work. Please check it works the same as before, I'm not very used to these lazyload and modal features.

abhishek@kumar: no offense, your comment seems spammy/generated by an LLM. Please avoid adding verbose comments which do not add value to the existing issue.

FieldOutputTest seems to need an update to reflect the new way it works.