Security patch released 20210518

It's a caching issue, I'm getting 1.1 when I click the link.
Something as simple as adding a trailing query for cache busting solves it:

Ideally this should be addressed.

1 Like

Yes, please read the above :slight_smile: ^^

Hint: why just don't do it in the link, for example:

or, better, the md5sum:


The content type for a hotfix behaves correctly but we have something in the stack that is over-caching, and we have tried purging unsuccessfully.

Seriously? Gah, I need to brush up on my search-and-replace skills. The project description on PyPI also has the wrong date.

I have fixed it in the code now. If we ever get a 1.3 version, you will see the correct dates. :slight_smile:


Before zest.releaser (thanks for that :beers:) there was a time where I used python <command> to push things to PyPI:

I think that running:

python register

will fix the PyPI page. IIRC I used it to fix pages with a broken rst syntax.

I think you can even test it with:

python register -r

I do not know if that still works, a lot of years have passed :slight_smile:


Version 1.2 might worth to send announcement

We noticed in our setup, that the behavior of the history diff view has changed:

Plone 5.2.1 (without hotfix)

Plone 5.2.1 (with hotfix)

After the hotfix all markup is escaped, whereas the XSS vulnerability description only refers to script tags.
I was wondering if this was so intended? Because this seems to be yet another code-diff view, which might confuse users.

We also made the same observation for Plone 4.x installations.


I see the same, I mean I can confirm that diff view has changed (Plone 5.0.5)

Yes, good idea – we were waiting to see if any other issues might be found with it.

You are right. I didn't realise that the hotfix would make the inline diff and code diff that much alike. Well, there are still differences, but with the hotfix the inline diff shows html code, so it has gotten uglier.

Here is the PR for merging the hotfix into Products.CMFDiffTool. After this is merged, someone could try to improve it.

With the hotfix, we call a simple function html_encode which escapes all html. We could change this to run the safe_html transform over it instead. That would get rid of script tags, but also other potentially dangerous tags or attributes. Not sure if that does the right thing, but worth a try.

One problem is that this is not just for rich text fields. The original report we got was: create a news item, then edit it to add an image with a specially crafted filename. Then look at the diff and some script was loaded.

1 Like

I'm still getting an error, when a PloneFormGen form has not filled all required fields:

  Module, line 135, in __call__
  Module Products.PloneHotfix20210518.expressions, line 63, in traverse
NotFound: _submit

 - Expression: "request/?env"
 - Filename:   ... cts/PloneFormGen/skins/PloneFormGen/
 - Location:   (line 187: col 38)
 - Source:     value request/?env"
 - Arguments:  repeat: {...} (0)
               template: <ImplicitAcquisitionWrapper fg_base_view_p3 at 0x7f8e2e4a2d70>
               modules: <instance - at 0x7f8e3a99a200>
               portal_type: formfolder

latest patch, Plone 5.1.5

any ideas?

the linked patch in PloneFormGen fixes this Problem too.

1 Like

You mentioned this but it’s not clear which patch you mean

I think he's referring to Fix breakage with the latest Plone Security Hotfix by dhavlik · Pull Request #229 · smcmahon/Products.PloneFormGen · GitHub


what he says :grin:

I have released Products.PloneFormGen 1.7.27 and 1.8.9.


I have released version 1.3 of the hotfix. See and

This version is fine for everyone, but should only be needed if you have problems with previous versions, especially getting more 404 NotFound errors than usual. From the changelog:

  • Allow accessing _authenticator from plone.protect in more cases. The previous version did this for a traverse class, and now also for a traverse function.
  • Allow accessing a single underscore _. After the merge of the hotfix, Zope allows this to fix a test failure. Seems wise to allow it in the hotfix too.
  • Define a set ALLOWED_UNDERSCORE_NAMES with allowed names. This currently contains __name__, _ and _authenticator. This makes it easier for projects to add a name in a patch if this is really needed. Be sure you know what you are doing if you override this.
  • Moved CHANGES.rst to main directory and add a version.txt there. This makes it easier to check that you have the correct version when you use the zip download from This file is cached, so you might get an earlier version. Check the sha1 or md5 checksum to be sure.

If the namedfile patch is there to prevent XSS from mimetypes like JS, SVG and HTML, why is it implemented as an allow-list with a random number of mimetypes instead of a block-list targeting exactly those which can lead to XSS?

The problem is that with this patch we a) decrease the user experience — e.g. PDFs can not be viewed in the browser anymore, they have to be downloaded (and the downloaded PDF might be viewed in the browser, but not the online version) — and b) we limit this to a random number of mime types, e.g. I don’t see support for Avif images.

Also, I don’t get the comment for the patch:

If a Manager has a use case for displaying those inline, there are other ways to create them, for example in the ZMI or via the Resource Registries or Theming control panel.

How should that be done when the list of allowed mimetypes is hard-coded in the patch? :thinking:

This is because there are probably other mimetypes that are vulnerable and that we did not want to miss. Just thinking out loud: maybe flash files, browser extensions, php or perl scripts, sass. Might also depend on which browser extensions you have.

I thought I had tested with a PDF before releasing the hotfix, and saw it still display inline, so I thought it was fine. In later testing I saw that I got a download. Not sure what went wrong there during the initial test. Might also differ per browser and depend on browser preferences that you have already configured.

PDF seems safe to add there yes. A patch in your own code could work, something like this (untested):

from Products.PloneHotfix20210518 import namedfile

I never heard of Avif images. I looked at the mimetypes registry object in the Plone Site and took the image types from there, except from SVG.

For clarity <img src="image.avif" /> would work exactly as before. Only <a href="image.avif" /> would be affected.

My idea was that in the ZMI you could add a plain OFS.Image instead of a namedfile. The hotfix only influences the handling of files/images from plone.namedfile.
I am actually not sure what type you get when you add an image in the resources registries or in the theming control panel, but I am guessing this is not a namedfile. Anyway, the ZMI would be the main way around this. But for sure it is not the nicest way.

1 Like