Where
-Infinity
0
Severity
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P

It was reported [1] that Plone suffers from a vulnerability that can be exploited to bypass certain security restrictions. This is due to a vulnerable bundled version of Zope.

Plone 3.x users that backported the fix for CVE-2011-0720 (PloneHotfix20110720) are affected due to the vulnerability being inadvertently backported via the hotfix.

A new hotfix (20110622) is available [2] to correct the flaw.

[1] http://plone.org/products/plone/security/advisories/20110622 [2] http://plone.org/products/plone-hotfix/releases/20110622

1 / 2
Source: Red Hat
First published (updated )
Severity
6.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Impact Various parts of Plone use the 'is url in portal' check for security, mostly to see if it is safe to redirect to a url. A url like https://example.org is not in the portal. But the url https:example.org without slashes tricks our code and it is considered to be in the portal. When redirecting, some browsers go to https://example.org, others give an error. Attackers may use this to redirect you to their site, especially as part of a phishing attack.

Patches The problem has been patched in Products.isurlinportal 1.2.0. This is a recommended upgrade for all users of Plone 4.3 and 5, on Python 2.7 or higher. It has not been tested on earlier Plone or Python versions. Upcoming Plone 5.2.5 and higher will include the new version.

Discovered This vulnerability was discovered and reported by Yuji Tounai of Mitsui Bussan Secure Directions, Inc. Thank you!

For more information If you have any questions or comments about this advisory: Email the Plone Security Team at security@plone.org, especially when you think you have discovered a security problem or when you are not sure. Open an issue in the tracker if your question or comment can be public.

1 / 2
Source: GitHub
First published (updated )
Severity
6.9
AV:L/AC:M/Au:N/C:C/I:C/A:C

DISPUTED postfixgroups.pl in Postfix 2.5.2 allows local users to overwrite arbitrary files via a symlink attack on the (1) /tmp/postfixgroups.stdout, (2) /tmp/postfixgroups.stderr, and (3) /tmp/postfixgroups.message temporary files. NOTE: the vendor disputes this vulnerability, stating "This is not a real issue ... users would have to edit a script under /usr/lib to enable it."

1 / 2
First published (updated )
Severity
2.1
Input Validation
AV:L/AC:L/Au:N/C:N/I:N/A:P

Postfix 2.4 before 2.4.9, 2.5 before 2.5.5, and 2.6 before 2.6-20080902, when used with the Linux 2.6 kernel, leaks epoll file descriptors during execution of "non-Postfix" commands, which allows local users to cause a denial of service (application slowdown or exit) via a crafted command, as demonstrated by a command in a .forward file.

First published (updated )

On Fri, Dec 29, 2023 at 12:50:55PM -0800, Alan Coopersmith wrote: On 12/26/23 11:15, Claus Assmann wrote: On Sun, Dec 24, 2023, Marcus Meissner wrote: - CVE-2023-51765 sendmail Can you update the text for this (or point me to the proper way/persons to do this)? https://www.cve.org/CVERecord?id=CVE-2023-51765 shows: Assigner: MITRE Corporation

so you can submit updates/corrections via the web form at: https://cveform.mitre.org/ Yes please use this form, or if you do not want one of us can do it.

I did not request the sendmail and exim CVEs, also the postfix CVE seems not my proposed description, so I guess someone else requested them.

Ciao, Marcus

Happy christmas list! On 24/12/2023 12.33, Marcus Meissner wrote: On Sat, Dec 23, 2023 at 02:29:34PM +0200, Valtteri Vuorikoski wrote: On Fri, Dec 22, 2023 at 11:46:48AM +0100, Marcus Meissner wrote: Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. Looks like exim opened a bug on this yesterday too, no sign of CVE yet: <https://bugs.exim.org/showbug.cgi?id=3063> CVEs are assigned now for:

- CVE-2023-51764 postfix - CVE-2023-51765 sendmail - CVE-2023-51766 exim

Ciao, Marcus

On Sat, Dec 23, 2023 at 02:29:34PM +0200, Valtteri Vuorikoski wrote: On Fri, Dec 22, 2023 at 11:46:48AM +0100, Marcus Meissner wrote: Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. Looks like exim opened a bug on this yesterday too, no sign of CVE yet: <https://bugs.exim.org/showbug.cgi?id=3063> CVEs are assigned now for:

- CVE-2023-51764 postfix - CVE-2023-51765 sendmail - CVE-2023-51766 exim

Ciao, Marcus

On 2023/12/22 11:46, Marcus Meissner wrote: Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. I'm a little confused by sec-consult's process here. They identify a problem affecting various pieces of software including some very widely deployed open source software, go to the trouble of doing a coordinated disclosure, but only do that with...looking at their timeline... gmx, microsoft and cisco?

Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers.

Ciao, Marcus On Thu, Dec 21, 2023 at 02:46:56PM +0000, Claus Assmann wrote: Just for completeness: sendmail 8.18.0.2 has options to handle this too, e.g., Accept only CR LF . CR LF as end of an SMTP message as required by the RFCs when the new srvfeatures option 'o' is used.

And for those who read the source code there's also an FFR: / enable checking for "bare LF" in message / "FFRBARELF",

Hi,

As if we did not have sufficient protocol vulnerability work short before Christmas break this year, here is one more:

https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

While it looks like "old stuff", this is new quality.

tldr: The end of "SMTP data phase" with "<CR><LF>.<CR><LF>" is not consistently implemented everywhere (e.g. when leaving out <CR> or inserting \0 or so) and could lead to one server passing it through and the other processing it, leading to mail spoofing.

The security report it for some custom email servers, but at least Postfix announced mitigation work already:

https://www.mail-archive.com/postfix-users () postfix org/msg100901.html

Ciao, Marcus

EOL
Apr 17, 2023

End of life: 4/17/2023, Latest version: 3.4.29

First published (updated )
EOL
Apr 17, 2023

End of life: 4/17/2023, Latest version: 3.4.29

First published (updated )
EOL
Feb 5, 2022

End of life: 2/5/2022, Latest version: 3.3.22

First published (updated )
EOL
Feb 5, 2022

End of life: 2/5/2022, Latest version: 3.3.22

First published (updated )
EOL
Apr 29, 2021

End of life: 4/29/2021, Latest version: 3.2.22

First published (updated )
EOL
Apr 29, 2021

End of life: 4/29/2021, Latest version: 3.2.22

First published (updated )
EOL
Mar 15, 2020

End of life: 3/15/2020, Latest version: 3.1.15

First published (updated )
EOL
Mar 15, 2020

End of life: 3/15/2020, Latest version: 3.1.15

First published (updated )
EOL
Feb 27, 2019

End of life: 2/27/2019, Latest version: 3.0.15

First published (updated )
EOL
Feb 27, 2019

End of life: 2/27/2019, Latest version: 3.0.15

First published (updated )
EOL
Feb 24, 2016

End of life: 2/24/2016, Latest version: 2.9.15

First published (updated )
EOL
Feb 24, 2016

End of life: 2/24/2016, Latest version: 2.9.15

First published (updated )
EOL
Feb 11, 2013

End of life: 2/11/2013, Latest version: 2.6.19

First published (updated )
EOL
Feb 11, 2013

End of life: 2/11/2013, Latest version: 2.6.19

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203