PerconaDB | Breaking Cybersecurity News | The Hacker News

Over a month ago we reported about two critical zero-day vulnerabilities in the world's 2nd most popular database management software MySQL: MySQL Remote Root Code Execution (CVE-2016-6662) Privilege Escalation (CVE-2016-6663) At that time, Polish security researcher Dawid Golunski of Legal Hackers who discovered these vulnerabilities published technical details and proof-of-concept exploit code for the first bug only and promised to release details of the second bug (CVE-2016-6663) later. On Tuesday, Golunski has released proof-of-concept (POC) exploits for two vulnerabilities: One is the previously promised critical privilege escalation vulnerability ( CVE-2016-6663 ), and another is a new root privilege escalation bug ( CVE-2016-6664 ) that could allow an attacker to take full control over the database. Both the vulnerabilities affect MySQL version 5.5.51 and earlier, MySQL version 5.6.32 and earlier, and MySQL version 5.7.14 and earlier, as well as MySQL forks

Two critical zero-day vulnerabilities have been discovered in the world's 2nd most popular database management software MySQL that could allow an attacker to take full control over the database. Polish security researcher Dawid Golunski has discovered two zero-days, CVE-2016-6662 and CVE-2016-6663, that affect all currently supported MySQL versions as well as its forked such as MariaDB and PerconaDB. Golunski further went on to publish details and a proof-of-concept exploit code for CVE-2016-6662 after informing Oracle of both issues, along with vendors of MariaDB and PerconaDB. Both MariaDB and PerconaDB had fixed the vulnerabilities, but Oracle had not. The vulnerability (CVE-2016-6662) can be exploited by hackers to inject malicious settings into MySQL configuration files or create their own malicious ones. Exploitation Vector The above flaw could be exploited either via SQL Injection or by hackers with authenticated access to MySQL database (via a network conne

Shadow apps, a segment of Shadow IT, are SaaS applications purchased without the knowledge of the security team. While these applications may be legitimate, they operate within the blind spots of the corporate security team and expose the company to attackers.  Shadow apps may include instances of software that the company is already using. For example, a dev team may onboard their own instance of GitHub to keep their work separate from other developers. They might justify the purchase by noting that GitHub is an approved application, as it is already in use by other teams. However, since the new instance is used outside of the security team's view, it lacks governance. It may store sensitive corporate data and not have essential protections like MFA enabled, SSO enforced, or it could suffer from weak access controls. These misconfigurations can easily lead to risks like stolen source code and other issues. Types of Shadow Apps  Shadow apps can be categorized based on their interac