The official plone Docker images before version of 4.3.18-alpine (Alpine specific) contain a blank password for a root user. System using the plone docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
Plone through 5.2.4 allows remote authenticated managers to perform disk I/O via crafted keyword arguments to the ReStructuredText transform in a Python script.
Plone CMS 3.0.5, and probably other 3.x versions, places a base64 encoded form of the username and password in the ac cookie for the admin account, which makes it easier for remote attackers to obtain administrative privileges by sniffing the network.
gtbn.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain permissions to bypass the Python sandbox and execute arbitrary Python code via unspecified vectors.
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.
A security flaw was found in the way Plone, a user friendly and powerful content management system, performed protection of privilege to run RestrictedPython scripts. A remote attacker could provide a specially-crafted URL that, when processed, would allow the attacker to submit and perform excessively expensive computations or (in conjuction with other attacks) to access or alter privileged information.
References: [1] http://plone.org/products/plone/security/advisories/20121106/04 [2] http://plone.org/products/plone/security/advisories/20121106/
Relevant upstream HotFixes: [3] http://plone.org/products/plone-hotfix/releases/20121106
From the OSS post: [4] http://www.openwall.com/lists/oss-security/2012/11/07/4
the pythonscripts.py createObject() change from upstream HotFix is relevant to this issue.
pythonscripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to "goback."
Plone upstream has published a pre-announcement about a security flaw, present in Zope v2.12.x and Zope v2.13.x, which could allow execution of arbitrary code by anonymous users. An authenticated attacker could provide a specially-crafted web page, which once visited by an unsuspecting Zope user would lead to arbitrary commands execution with the privileges of the Zope/Plone service.
References: [1] http://plone.org/products/plone/security/advisories/20110928 [2] http://secunia.com/advisories/46221/
Note: The vendor announced the final version of the advisory and the patch to be available at 2011-10-04 15:00 UTC at the following location: [3] http://plone.org/products/plone/security/advisories/20110928
The CMFEditions component 2.x in Plone 4.0.x through 4.0.9, 4.1, and 4.2 through 4.2a2 does not prevent the KwAsAttributes classes from being publishable, which allows remote attackers to access sub-objects via unspecified vectors, a different vulnerability than CVE-2011-3587.
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-0720 to the following vulnerability:
Name: CVE-2011-0720 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0720 Assigned: 20110131 Reference: http://plone.org/products/plone/security/advisories/cve-2011-0720 Reference: http://www.securityfocus.com/bid/46102 Reference: http://secunia.com/advisories/43146 Reference: http://xforce.iss.net/xforce/xfdb/65099
Unspecified vulnerability in Plone 2.5 through 4.0 allows remote attackers to obtain administrative access, read or create arbitrary content, and change the site skin via unknown vectors.
The hotfix for this issue is available here: http://plone.org/products/plone-hotfix/releases/CVE-2011-0720/
Some Plone components are included in conga, so this flaw may have some impact there.
Plone before 5.2.3 allows XXE attacks via a feature that is explicitly only available to the Manager role.
Plone before 5.2.3 allows XXE attacks via a feature that is protected by an unapplied permission of plone.schemaeditor.ManageSchemata (therefore, only available to the Manager role).
Plone before 5.2.3 allows SSRF attacks via the tracebacks feature (only available to the Manager role).
Multiple cross-site request forgery (CSRF) vulnerabilities in Zope Management Interface 4.3.7 and earlier, and Plone before 5.x.
Impact Most Python modules are not available for using in TAL expressions that you can add through-the-web, for example in Zope Page Templates. This restriction avoids file system access, for example via the 'os' module. But some of the untrusted modules are available indirectly through Python modules that are available for direct use.
By default, you need to have the Manager role to add or edit Zope Page Templates through the web. Only sites that allow untrusted users to add/edit Zope Page Templates through the web are at risk.
Patches The problem has been fixed in Zope 5.2 and 4.6.
Workarounds A site administrator can restrict adding/editing Zope Page Templates through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing Zope Page Templates through the web should be restricted to trusted users only.
For more information If you have any questions or comments about this advisory: Open an issue in the Zope issue tracker Email us at security@plone.org
An issue in Plone CMS allows attacker to access sensitive information via the RSS feed protlet.
Due to incorrect access control in Plone version v6.0.9, remote attackers can view and list all files hosted on the website via sending a crafted request.
AccessControl/AuthEncoding.py in Zope before 2.13.19, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote attackers to obtain passwords via vectors involving timing discrepancies in password validation.
A HTTP header injection flaw was found in the way Plone, a user friendly and powerful content management system, performed sanitization of HTTP headers provided within certain URL requests. A remote attacker could provide a specially-crafted URL that, when processed would lead the injected HTTP headers to be returned as part of Plone system HTTP response (possibly leading to HTTP response splitting, cross-site scripting [XSS] flaws, session fixation or unauthorized HTTP redirect attacks - to mention some of the possible negative consequences).
References: [1] http://plone.org/products/plone/security/advisories/20121106/02 [2] http://plone.org/products/plone/security/advisories/20121106/
Relevant upstream HotFixes: [3] http://plone.org/products/plone-hotfix/releases/20121106
From the OSS post: [4] http://www.openwall.com/lists/oss-security/2012/11/07/4
the setHeader.py change from upstream HotFix is relevant to this issue.
ftp.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to read hidden folder contents via unspecified vectors.
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
Plone though 5.2.4 allows SSRF via the lxml parser. This affects Diazo themes, Dexterity TTW schemas, and modeleditors in plone.app.theming, plone.app.dexterity, and plone.supermodel.
Plone 4.1.3 and earlier computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters.
Plone CMS before 3 places a base64 encoded form of the username and password in the ac cookie for all user accounts, which makes it easier for remote attackers to obtain access by sniffing the network.
Plone CMS does not record users' authentication states, and implements the logout feature solely on the client side, which makes it easier for context-dependent attackers to reuse a logged-out session.
Multiple cross-site request forgery (CSRF) vulnerabilities in Plone CMS 3.0.5 and 3.0.6 allow remote attackers to (1) add arbitrary accounts via the joinform page and (2) change the privileges of arbitrary groups via the prefsgroupsoverview page.
A vulnerability was found allowing users who have access to write cookie values were able to inject headers into the response. Versions affected are all versions Plone 3.
Upstream hotfix:
https://plone.org/security/20150910/
CVE request:
http://seclists.org/oss-sec/2015/q3/589
A denial of service flaw was found in the way Plone, a user friendly and powerful content management system, performed processing of very large values passed to an internal utility function being exposed on an URL. A remote attacker could provide a specially-crafted URL that, when processed would lead to excessive memory consumption.
References: [1] http://plone.org/products/plone/security/advisories/20121106/15 [2] http://plone.org/products/plone/security/advisories/20121106/
Relevant upstream HotFixes: [3] http://plone.org/products/plone-hotfix/releases/20121106
From the OSS post: [4] http://www.openwall.com/lists/oss-security/2012/11/07/4
the pythonscripts.py formatColumns() change from upstream HotFix is relevant to this issue.
The isURLInPortal method in the URLTool class in inportal.py in Plone 2.1 through 4.1, 4.2.x through 4.2.5, and 4.3.x through 4.3.1 treats URLs starting with a space as a relative URL, which allows remote attackers to bypass the allowexternalloginsites filtering property, redirect users to arbitrary web sites, and conduct phishing attacks via a space before a URL in the "next" parameter to aclusers/credentialscookieauth/requirelogin.
A denial of service flaw was found in the way Plone, a user friendly and powerful content management system, performed processing of requests for certain collections. A remote attacker could provide a specially-crafted URL that, when processed would lead to excessive I/O and / or cache resources consumption.
References: [1] http://plone.org/products/plone/security/advisories/20121106/14 [2] http://plone.org/products/plone/security/advisories/20121106/
Relevant upstream HotFixes: [3] http://plone.org/products/plone-hotfix/releases/20121106
From the OSS post: [4] http://www.openwall.com/lists/oss-security/2012/11/07/4
the queryCatalog.py change from upstream HotFix is relevant to this issue.