Security-news

security-news@drupal.org

1 participants
1782 discussions

Drupal core - Moderately critical - Cross-site scripting - SA-CORE-2020-010
by security-news＠drupal.org 16 Sep '20

16 Sep '20

View online: https://www.drupal.org/sa-core-2020-010 Project: Drupal core [1] Date: 2020-September-16 Security risk: *Moderately critical* 13∕25 AC:Basic/A:User/CI:Some/II:Some/E:Theoretical/TD:Default [2] Vulnerability: Cross-site scripting CVE IDs: CVE-2020-13669 Description: Drupal core's built-in CKEditor image caption functionality is vulnerable to XSS. Solution: Install the latest version: * If you are using Drupal 8.8.x, upgrade to Drupal 8.8.10 [3]. * If you are using Drupal 8.9.x, upgrade to Drupal 8.9.6 [4]. * If you are using Drupal 9.0.x, upgrade to Drupal 9.0.6 [5]. Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10. Reported By: * Dor Tumarkin [6] * Krzysztof Krzton [7] Fixed By: * Samuel Mortenson [8] of the Drupal Security Team * Wim Leers [9] * Henrik Danielsson [10] * Dor Tumarkin [11] * Jess [12] of the Drupal Security Team * Krzysztof Krzton [13] * Lee Rowlands [14] of the Drupal Security Team [1] https://www.drupal.org/project/drupal [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/drupal/releases/8.8.10 [4] https://www.drupal.org/project/drupal/releases/8.9.6 [5] https://www.drupal.org/project/drupal/releases/9.0.6 [6] https://www.drupal.org/user/3648639 [7] https://www.drupal.org/user/3618903 [8] https://www.drupal.org/user/2582268 [9] https://www.drupal.org/user/99777 [10] https://www.drupal.org/user/244227 [11] https://www.drupal.org/user/3648639 [12] https://www.drupal.org/user/65776 [13] https://www.drupal.org/user/3618903 [14] https://www.drupal.org/user/395439

1 0

Drupal core - Critical - Cross-site scripting - SA-CORE-2020-009
by security-news＠drupal.org 16 Sep '20

16 Sep '20

View online: https://www.drupal.org/sa-core-2020-009 Project: Drupal core [1] Date: 2020-September-16 Security risk: *Critical* 15∕25 AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:Default [2] Vulnerability: Cross-site scripting CVE IDs: CVE-2020-13668 Description: Drupal 8 and 9 have a reflected cross-site scripting (XSS) vulnerability under certain circumstances. An attacker could leverage the way that HTML is rendered for affected forms in order to exploit the vulnerability. Solution: Install the latest version: * If you are using Drupal 8.8.x, upgrade to Drupal 8.8.10 [3]. * If you are using Drupal 8.9.x, upgrade to Drupal 8.9.6 [4]. * If you are using Drupal 9.0.x, upgrade to Drupal 9.0.6 [5]. Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10. In addition to updating Drupal core, sites that override \Drupal\Core\Form\FormBuilder's renderPlaceholderFormAction() and/or buildFormAction() methods in contrib and/or custom code should ensure that appropriate sanitization is applied for URLs. Reported By: * Nuno Ramos [6] * markwittens [7] * Nathan Dentzau [8] * Marc Addeo [9] * Alejandro Garza [10] Fixed By: * Lee Rowlands [11] of the Drupal Security Team * David Rothstein [12] of the Drupal Security Team * Wim Leers [13] * Vijay Mani [14], provisional member of the Drupal Security Team * Drew Webber [15] of the Drupal Security Team * Nathan Dentzau [16] * Heine [17] of the Drupal Security Team * Joseph Zhao [18], provisional member of the Drupal Security Team * Jess [19] of the Drupal Security Team * Tim Plunkett [20] [1] https://www.drupal.org/project/drupal [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/drupal/releases/8.8.10 [4] https://www.drupal.org/project/drupal/releases/8.9.6 [5] https://www.drupal.org/project/drupal/releases/9.0.6 [6] https://www.drupal.org/user/3522063 [7] https://www.drupal.org/user/567198 [8] https://www.drupal.org/user/3444913 [9] https://www.drupal.org/user/3312527 [10] https://www.drupal.org/user/153120 [11] https://www.drupal.org/user/395439 [12] https://www.drupal.org/user/124982 [13] https://www.drupal.org/user/99777 [14] https://www.drupal.org/user/93488 [15] https://www.drupal.org/user/255969 [16] https://www.drupal.org/user/3444913 [17] https://www.drupal.org/user/17943 [18] https://www.drupal.org/user/1987218 [19] https://www.drupal.org/user/65776 [20] https://www.drupal.org/user/241634

1 0

Drupal core - Moderately critical - Access bypass - SA-CORE-2020-008
by security-news＠drupal.org 16 Sep '20

16 Sep '20

View online: https://www.drupal.org/sa-core-2020-008 Project: Drupal core [1] Date: 2020-September-16 Security risk: *Moderately critical* 12∕25 AC:Basic/A:None/CI:Some/II:None/E:Theoretical/TD:Default [2] Vulnerability: Access bypass CVE IDs: CVE-2020-13667 Description: The experimental Workspaces module allows you to create multiple workspaces on your site in which draft content can be edited before being published to the live workspace. The Workspaces module doesn't sufficiently check access permissions when switching workspaces, leading to an access bypass vulnerability. An attacker might be able to see content before the site owner intends people to see the content. This vulnerability is mitigated by the fact that sites are only vulnerable if they have installed the experimental Workspaces module. Solution: Install the latest version: * If you are using Drupal 8.8.x, upgrade to Drupal 8.8.10 [3]. * If you are using Drupal 8.9.x, upgrade to Drupal 8.9.6 [4]. * If you are using Drupal 9.0.x, upgrade to Drupal 9.0.6 [5]. Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10. Once a site running Workspaces is upgraded, authenticated users may continue to see unauthorized workspace content that they accessed previously until they are logged out. If it is important for the unintended access to stop immediately, you may wish to end all active user sessions on your site (for example, by truncating the sessions table). Be aware that this will immediately log all users out and can cause side effects like lost user input. Reported By: * Andrei Mateescu [6] Fixed By: * Andrei Mateescu [7] * Jess [8] of the Drupal Security Team * Nathaniel Catchpole [9] of the Drupal Security Team * Lee Rowlands [10] of the Drupal Security Team * Greg Knaddison [11] of the Drupal Security Team * Dick Olsson [12] [1] https://www.drupal.org/project/drupal [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/drupal/releases/8.8.10 [4] https://www.drupal.org/project/drupal/releases/8.9.6 [5] https://www.drupal.org/project/drupal/releases/9.0.6 [6] https://www.drupal.org/user/729614 [7] https://www.drupal.org/user/729614 [8] https://www.drupal.org/user/65776 [9] https://www.drupal.org/user/35733 [10] https://www.drupal.org/user/395439 [11] https://www.drupal.org/user/36762 [12] https://www.drupal.org/user/239911

1 0

Drupal core - Moderately critical - Cross-site scripting - SA-CORE-2020-007
by security-news＠drupal.org 16 Sep '20

16 Sep '20

View online: https://www.drupal.org/sa-core-2020-007 Project: Drupal core [1] Date: 2020-September-16 Security risk: *Moderately critical* 14∕25 AC:Basic/A:User/CI:Some/II:Some/E:Theoretical/TD:All [2] Vulnerability: Cross-site scripting CVE IDs: CVE-2020-13666 Description: The Drupal AJAX API does not disable JSONP by default, which can lead to cross-site scripting. Solution: Install the latest version: * If you are using Drupal 7.x, upgrade to Drupal 7.73 [3]. * If you are using Drupal 8.8.x, upgrade to Drupal 8.8.10 [4]. * If you are using Drupal 8.9.x, upgrade to Drupal 8.9.6 [5]. * If you are using Drupal 9.0.x, upgrade to Drupal 9.0.6 [6]. Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10. If you were previously relying on Drupal's AJAX API to perform trusted JSONP requests, you'll either need to override the AJAX options to set "jsonp: true", or you'll need to use the jQuery AJAX API directly. If you are using jQuery's AJAX API for user-provided URLs in a contrib or custom module, you should review your code and set "jsonp: false" where this is appropriate. Reported By: * Samuel Mortenson [7] of the Drupal Security Team Fixed By: * Samuel Mortenson [8] of the Drupal Security Team * Théodore Biadala [9] * Lee Rowlands [10] of the Drupal Security Team * David Snopek [11] of the Drupal Security Team * Nathaniel Catchpole [12] of the Drupal Security Team * Alex Bronstein [13] of the Drupal Security Team * Drew Webber [14] of the Drupal Security Team [1] https://www.drupal.org/project/drupal [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/drupal/releases/7.73 [4] https://www.drupal.org/project/drupal/releases/8.8.10 [5] https://www.drupal.org/project/drupal/releases/8.9.6 [6] https://www.drupal.org/project/drupal/releases/9.0.6 [7] https://www.drupal.org/user/2582268 [8] https://www.drupal.org/user/2582268 [9] https://www.drupal.org/user/598310 [10] https://www.drupal.org/user/395439 [11] https://www.drupal.org/user/266527 [12] https://www.drupal.org/user/35733 [13] https://www.drupal.org/user/78040 [14] https://www.drupal.org/user/255969

1 0

Group - Moderately critical - Information disclosure - SA-CONTRIB-2020-033
by security-news＠drupal.org 05 Aug '20

05 Aug '20

View online: https://www.drupal.org/sa-contrib-2020-033 Project: Group [1] Version: 8.x-1.x-dev Date: 2020-August-05 Security risk: *Moderately critical* 11∕25 AC:None/A:User/CI:Some/II:None/E:Theoretical/TD:Uncommon [2] Vulnerability: Information disclosure Description: The Group module enables you to hand out permissions on a smaller subset, section or community of your website. Under very specific circumstances, where two group types support the same content, yet hand out different permissions, non-members of the first group type may use the set of permissions of the 2nd group type for the grouped content. This vulnerability is mitigated by the fact that you must already have a rare set-up and the two group types are configured in a way where one is more permissive than the other over the same type of content. Solution: Install the latest version: * If you are using 8.x-1.0 [3] or later, you should upgrade to 8.x-1.2 [4]. * If you are using 8.x-1.0-rc5 [5], that version is not affected by this issue. You can also consider upgrading to 8.x-1.2 [6]. Reported By: * John Pitcairn [7] Fixed By: * Kristiaan Van den Eynde [8] [1] https://www.drupal.org/project/group [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/group/releases/8.x-1.0 [4] https://www.drupal.org/project/group/releases/8.x-1.2 [5] https://www.drupal.org/project/group/releases/8.x-1.0-rc5 [6] https://www.drupal.org/project/group/releases/8.x-1.2 [7] https://www.drupal.org/user/425866 [8] https://www.drupal.org/user/1345130

1 0

Group - Moderately critical - Information disclosure - SA-CONTRIB-2020-032
by security-news＠drupal.org 05 Aug '20

05 Aug '20

View online: https://www.drupal.org/sa-contrib-2020-032 Project: Group [1] Version: 8.x-1.x-dev Date: 2020-August-05 Security risk: *Moderately critical* 12∕25 AC:Basic/A:None/CI:Some/II:None/E:Theoretical/TD:Default [2] Vulnerability: Information disclosure Description: The Group module enables you to hand out permissions on a smaller subset, section or community of your website. With the 1.1 security release, new code was introduced to ensure proper access for all entity types, but a mistake introduced unexpected access to unpublished nodes. Solution: Install the latest version: * If you are using 8.x-1.0 [3] or later, you should upgrade to 8.x-1.2 [4]. * If you are using 8.x-1.0-rc5 [5], that version is not affected by this issue. You can also consider upgrading to 8.x-1.2 [6]. Reported By: * Sean Blommaert [7] * Martijn Vermeulen [8] Fixed By: * Kristiaan Van den Eynde [9] [1] https://www.drupal.org/project/group [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/group/releases/8.x-1.0 [4] https://www.drupal.org/project/group/releases/8.x-1.2 [5] https://www.drupal.org/project/group/releases/8.x-1.0-rc5 [6] https://www.drupal.org/project/group/releases/8.x-1.2 [7] https://www.drupal.org/user/545912 [8] https://www.drupal.org/user/960720 [9] https://www.drupal.org/user/1345130

1 0

Hostmaster (Aegir) - Moderately critical - Access bypass, Arbitrary code execution - SA-CONTRIB-2020-031
by security-news＠drupal.org 29 Jul '20

29 Jul '20

View online: https://www.drupal.org/sa-contrib-2020-031 Project: Hostmaster (Aegir) [1] Version: 7.x-3.x-dev Date: 2020-July-29 Security risk: *Moderately critical* 14∕25 AC:Complex/A:Admin/CI:All/II:All/E:Theoretical/TD:Uncommon [2] Vulnerability: Access bypass, Arbitrary code execution Description: Aegir [3] is a powerful hosting system that sits alongside a LAMP or LEMP server to create, deploy and manage Drupal sites. Given that * Aegir can use both Apache and Nginx Web servers, * Apache allows configuration-writing users to escalate their privileges to the superuser root, and * Aegir's operations are performed by the GNU/Linux user aegir, It follows that: * Users with access to the aegir account can escalate their privileges to root. * Any PHP code submitted through the front-end Web UI via enabling modules (such as PHP [4], Views PHP [5], and Computed Field [6]) could be run as root though a cron [7] hook implementation [8]. (Aegir runs cron through the aegir user via Drush [9].) This vulnerability is mitigated by the fact that * an attacker must have access to the aegir account, and * the Web server must be Apache. While it was generally assumed that aegir access should only be provided to trusted users (i.e. users who also have access to root), this wasn't explicitly stated. The documentation has since been updated. Solution: If you're running Aegir and have granted untrusted users access to the aegir account, 1) revoke aegir account access for users who you would not trust with root access, 2) disable any module functionality on the hosted Drupal sites that allows PHP code to be entered on the front-end Web UI. Computed Field, for example, can still be used safely by providing code from the back-end only. (See Stop allowing PHP from being entered on the Web UI [10] for a plan to enforce this.) We do not recommend switching to an Nginx Web server instead of revoking access. This is because there could be as-yet-unknown privilege-escalation exploits involving Nginx (as with any other piece of software). /Switching to Nginx/ While not recommended, if this is something you'd like to do in addition to making the above change, we can offer some information on how to do it. While there may eventually be a migration path to convert existing Apache installations to Nginx, the recommended approach is currently: 1) Set up a new Aegir installation [11] using Nginx. 2) Remotely import sites [12] from the original Apache server. 3) Decommission the original Apache server. Also see the Hostmaster (Aegir) [13] project page. Reported By: * Noam Rathaus [14] Fixed By: * Colan Schwartz [15] Coordinated By: * Heine [16]of the Drupal Security Team * Greg Knaddison [17]of the Drupal Security Team [1] https://www.drupal.org/project/hostmaster [2] https://www.drupal.org/security-team/risk-levels [3] https://www.aegirproject.org/ [4] https://www.drupal.org/project/php [5] https://www.drupal.org/project/views_php [6] https://www.drupal.org/project/computed_field [7] https://www.drupal.org/docs/administering-a-drupal-site/cron-automated-task… [8] https://www.drupal.org/docs/creating-custom-modules/understanding-hooks [9] https://en.wikipedia.org/wiki/Drush [10] https://www.drupal.org/project/computed_field/issues/3143854 [11] https://docs.aegirproject.org/install/ [12] https://docs.aegirproject.org/usage/sites/importing/#remote-import [13] https://www.drupal.org/project/hostmaster [14] https://www.drupal.org/user/3645736 [15] https://www.drupal.org/user/58704 [16] https://www.drupal.org/user/17943 [17] https://www.drupal.org/user/36762

1 0

Group - Critical - Information Disclosure - SA-CONTRIB-2020-030
by security-news＠drupal.org 29 Jul '20

29 Jul '20

View online: https://www.drupal.org/sa-contrib-2020-030 Project: Group [1] Version: 8.x-1.x-dev Date: 2020-July-29 Security risk: *Critical* 15∕25 AC:None/A:None/CI:Some/II:None/E:Theoretical/TD:All [2] Vulnerability: Information Disclosure Description: This module enables you to hand out permissions on a smaller subset, section or community of your website. The module used to leverage the node grants system but turned it off in its recent 8.x-1.0 release in favor of a system that works for ALL entity types, not just nodes. By doing so, some regular node access checks turned from neutral into allowed because of the way the node grants system operates. This vulnerability is mitigated by the fact that an attacker must have the GroupNode plugin installed on their website and have no other hook_node_grants() implementations on their website aside from the one that was recently removed by Group. If you do not use the GroupNode plugin or still have hook_node_grants() implementing modules enabled, your site may not be affected. Solution: Install the latest version: * If you are using 8.x-1.0-rc5 you can keep using that version or upgrade to 8.x-1.1 [3] * If you are using 8.x-1.0 you should upgrade to 8.x-1.1 [4] Reported By: * Kristiaan Van den Eynde [5] Fixed By: * Kristiaan Van den Eynde [6] Coordinated By: * Greg Knaddison [7] Of the Drupal Security Team [1] https://www.drupal.org/project/group [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/group/releases/8.x-1.1 [4] https://www.drupal.org/project/group/releases/8.x-1.1 [5] https://www.drupal.org/user/1345130 [6] https://www.drupal.org/user/1345130 [7] https://www.drupal.org/u/greggles

1 0

Modal Form - Critical - Access bypass - SA-CONTRIB-2020-029
by security-news＠drupal.org 22 Jul '20

22 Jul '20

View online: https://www.drupal.org/sa-contrib-2020-029 Project: Modal Form [1] Version: 8.x-1.x-dev Date: 2020-July-22 Security risk: *Critical* 16∕25 AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:All [2] Vulnerability: Access bypass Description: The Modal form module is a toolset for quick start of using forms in modal windows. Any form is available for view and submit when the modal_form module is installed. The only requirement is to know the form's fully-qualified class name. Solution: Upgrade to modal_form-8.x-1.2 [3]. Also see the Modal Form [4] project page. Reported By: * Dave Long [5] Fixed By: * Sergii Bondarenko [6] Coordinated By: * Greg Knaddison [7] of the Drupal Security Team [1] https://www.drupal.org/project/modal_form [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/modal_form/releases/8.x-1.2 [4] https://www.drupal.org/project/modal_form [5] https://www.drupal.org/user/246492 [6] https://www.drupal.org/user/2802285 [7] https://www.drupal.org/user/36762

1 0

Apigee Edge - Moderately critical - Access bypass - SA-CONTRIB-2020-028
by security-news＠drupal.org 22 Jul '20

22 Jul '20

View online: https://www.drupal.org/sa-contrib-2020-028 Project: Apigee Edge [1] Version: 8.x-1.x-dev Date: 2020-July-22 Security risk: *Moderately critical* 10∕25 AC:Basic/A:User/CI:Some/II:None/E:Theoretical/TD:Default [2] Vulnerability: Access bypass Description: The Apigee Edge module allows connecting a Drupal site to Apigee Edge in order to build a developer portal. It contains an "Apigee Edge Teams" submodule that provides shared app functionality by allowing developers to be organized into teams. The "Apigee Edge Teams" submodule has an information disclosure vulnerability. The "Add team member" form displays an email autocomplete field which can expose the email addresses of other accounts in the system. This vulnerability is mitigated by the fact that to have access to the form, the site must have the Apigee Edge Teams submodule enabled, and the user must have a team role that has the "Manage team members" permission. (Note that team roles and permissions are not related to Drupal core roles and permissions). Solution: Install the latest version: * If you use the apigee_edge_teams submodule for Drupal 8.x, upgrade to Apigee Edge module 8.x-1.12 [3] Also see the Apigee Edge [4] project page. Reported By: * Arlina Espinoza Rhoton [5] Fixed By: * Arlina Espinoza Rhoton [6] * Chris Novak [7] Coordinated By: * Greg Knaddison [8] of the Drupal Security Team [1] https://www.drupal.org/project/apigee_edge [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/apigee_edge/releases/8.x-1.12 [4] https://www.drupal.org/project/apigee_edge [5] https://www.drupal.org/user/1055344 [6] https://www.drupal.org/user/1055344 [7] https://www.drupal.org/user/880416 [8] https://www.drupal.org/user/36762

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Security-news