* Sylvain Beucler: " Re: CVE triage for several issues in Tryton" (Fri, 18 Sep 2026 16:12:27 +0200):
Hi, > Thanks for your work on Tryton. Can you precise a little bit the context > here, do you plan a bookworm update? Well, I am searching for feedback which updates would be applicable and I could prepare those. > On 17/09/2026 12:14, Mathias Behrle wrote: > > several security issues were found and are fixed in unstable, forky and > > trixie. > > > > 1) > > > > tryton-server: > > https://discuss.tryton.org/t/security-release-for-issue-14947/9302 > > Forbid weasyprint to access local files > > > > https://salsa.debian.org/tryton-team/tryton-server/-/blob/debian-trixie/debian/patches/08_restrict_weasyprint_protocol.patch?ref_type=heads > > > > The patch is applicable on tryton-server in bookworm, but requires > > 'weasyprint >= 68.0' while bookworm has 57.2-1. > > Is there a CVE (or TEMP) for this? > Also the referenced https://bugs.tryton.org/14947 is now 404. There is no CVE (or TEMP) yet, the issue was found in the same run with the other issues. It is prinicipally related to https://github.com/Kozea/WeasyPrint/releases/tag/v68.0 https://security-tracker.debian.org/tracker/CVE-2025-68616 It was forgotten to disclose the bug which reads as: " Forbid weasyprint to access local files Confidential created 2 months ago by Cédric Krier The weasyprint documentation states that it can be used to access local files. We should probably use a custom fetcher which forbid file:// protocol. " The patch (s. above) is the verbatim patch skipping pyroject.toml (for the weasyprint version requirement) and CHANGELOG. > So I lack the full context, but various theoretical solutions exists: > - patching weasyprint to provide the required feature, > - bumping weasyprint as it seems to only have reverse-recommends from > tryton packages and is apparently unused by other packages in bookworm weasyprint is marked as no DSA for trixie and bookworm for https://security-tracker.debian.org/tracker/CVE-2025-68616 Bumping weasyprint would solve as well https://security-tracker.debian.org/tracker/CVE-2026-49452 > > 2) > > > > https://security-tracker.debian.org/tracker/TEMP-0000000-9D9504 > > Python code execution via uploaded templates > > > > https://discuss.tryton.org/t/security-release-for-issue-5160-and-14869/9266/3 > > https://salsa.debian.org/tryton-team/tryton-server/-/blob/debian-trixie/debian/patches/06_restrict_genshi_evaluation.patch?ref_type=heads > > > > The patch to restrict genshi evaluation applies, but there is a caveat: > > custom reports could fail, if they use the forbidden functions. > > This could be added to the DLA text and/or to a NEWS file to warn users. > > > This patch could be deployed. > > > > > > https://discuss.tryton.org/t/security-release-for-issue-14907/9267/1 > > https://salsa.debian.org/tryton-team/tryton-server/-/blob/debian-trixie/debian/patches/07_enforce_access_right_on_email_template_records.patch?ref_type=heads > > > > The changes made by those patches are rather intrusive, so this patch could > > not be deployed IMO. > I assume this is a second fix for TEMP-0000000-9D9504. > > In some cases there are more risks in applying a complex patch, than to > leave the issue unfixed. AFAIU this allows a registered Tryton user to > take over its server, which sounds severe, so hopefully an alternate fix > or a mitigation can be proposed to users. There is no other workaround than just to not use the modules marketing_automation and marketing_email, which allow users to write their own genshi templates (if we only look at Tryton standard modules). I just get aware that those modules were not yet available in Tryton series 6.0. So for me it will be better to not apply the server patch even if the underlying problem will remain unfixed (and there is a probably negligible probability that someone uses the feature in own custom modules). Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
pgpUUTk1oTgYq.pgp
Description: Digitale Signatur von OpenPGP
