# Applebee's Exposed Customers' Personal Data After Leaving Database Password In App
robot (spnet, 1) → All – 00:22:02 2026-11-06
Joe_Dragon shares a report from TechCrunch: Applebee's has fixed a security flaw that allowed anyone to access the personal information of its registered customers, after a researcher found a password for an internal database inside Applebee's mobile app, TechCrunch has learned. The popular restaurant chain confirmed [last Thursday] that it had taken action to address the security issue to prevent any unauthorized access to its customer database. [...] The exposed database contained customer names, email addresses (including whether or not the customer verified their email), dates of birth, phone numbers, and ZIP codes. The data also included veteran status, the number of times customers had logged in, when their accounts were created, and the IP addresses of their most recent log-ins, which can be used to reveal the person's approximate location.
[...] When asked by TechCrunch, the spokesperson would not say if the company has server logs that it can review to determine whether anyone accessed the database, or if it has any logs at all. "Our investigation is ongoing, and we will take appropriate steps based on our findings," the company added. It's unclear how many customers were affected by the data exposure. [...] Applebee's had at least 8.5 million customers enrolled in its rewards program as of last year, though the company would not provide a number of how many customers had their personal information exposed by this security flaw.
[ Read more of this story ]( https://yro.slashdot.org/story/26/11/05/2230215/applebees-exposed-customers-personal-data-after-leaving-database-password-in-app?utm_source=atom1.0moreanon&utm_medium=feed ) at Slashdot.
robot (spnet, 1) → All – 00:22:02 2026-11-06
Joe_Dragon shares a report from TechCrunch: Applebee's has fixed a security flaw that allowed anyone to access the personal information of its registered customers, after a researcher found a password for an internal database inside Applebee's mobile app, TechCrunch has learned. The popular restaurant chain confirmed [last Thursday] that it had taken action to address the security issue to prevent any unauthorized access to its customer database. [...] The exposed database contained customer names, email addresses (including whether or not the customer verified their email), dates of birth, phone numbers, and ZIP codes. The data also included veteran status, the number of times customers had logged in, when their accounts were created, and the IP addresses of their most recent log-ins, which can be used to reveal the person's approximate location.
[...] When asked by TechCrunch, the spokesperson would not say if the company has server logs that it can review to determine whether anyone accessed the database, or if it has any logs at all. "Our investigation is ongoing, and we will take appropriate steps based on our findings," the company added. It's unclear how many customers were affected by the data exposure. [...] Applebee's had at least 8.5 million customers enrolled in its rewards program as of last year, though the company would not provide a number of how many customers had their personal information exposed by this security flaw.
[ Read more of this story ]( https://yro.slashdot.org/story/26/11/05/2230215/applebees-exposed-customers-personal-data-after-leaving-database-password-in-app?utm_source=atom1.0moreanon&utm_medium=feed ) at Slashdot.
# OpenAI Responds to US Midterm Elections With New Commitment to Communities
robot (spnet, 1) → All – 23:22:01 2026-11-05
"OpenAI has published a new National Community Compact and Compute Campus Policy Blueprint, apparently in response to the Blue Wave Midterm Elections," writes ancient Slashdot reader Gilmoure. "Instead of moving into communities like a juggernaut, they say they will be dangling friendly carrots going forward." Here's an excerpt from OpenAI's article: Every future compute campus OpenAI owns and operates will have its own local compact. We'll engage residents early enough to ensure their input shapes project plans, give them a local point of contact throughout the life of the campus, and report publicly each year on how we're doing. Each compact will reflect local priorities and include a common set of commitments:
- Pay our own way on energy and infrastructure. We'll pay the full cost of the electricity we use and the infrastructure needed to serve us. Before major spending begins, we'll provide financial assurances so other customers are protected if a project is delayed, reduced, or canceled.
- Protect local resources and report on our impact. We'll develop a water plan for each campus, prioritize closed-loop or low-water cooling, and publish site-level water and electricity use. We'll publish construction plans and independent noise studies before operations begin and annually afterward. And we will not use non-disclosure agreements (NDAs) with public officials, allowing only narrow protections covering legitimate security information, trade secrets, or proprietary or competitively sensitive information.
- Create opportunities for local workers and businesses. We'll publish the jobs we expect to create, work with unions and training providers to help residents prepare for them, and report annually on hiring and apprenticeships. We'll also make sustained investments in priorities residents help select.
[...] The investments that help America compete globally can also help communities prosper locally. That starts with giving residents a say while plans can still change and a way to hold developers accountable for delivering on their commitments. That's what we're committing to at the campuses we own and operate, and what we believe people should be able to count on wherever AI infrastructure is built across the country.
[ Read more of this story ]( https://politics.slashdot.org/story/26/11/05/2150249/openai-responds-to-us-midterm-elections-with-new-commitment-to-communities?utm_source=atom1.0moreanon&utm_medium=feed ) at Slashdot.
robot (spnet, 1) → All – 23:22:01 2026-11-05
"OpenAI has published a new National Community Compact and Compute Campus Policy Blueprint, apparently in response to the Blue Wave Midterm Elections," writes ancient Slashdot reader Gilmoure. "Instead of moving into communities like a juggernaut, they say they will be dangling friendly carrots going forward." Here's an excerpt from OpenAI's article: Every future compute campus OpenAI owns and operates will have its own local compact. We'll engage residents early enough to ensure their input shapes project plans, give them a local point of contact throughout the life of the campus, and report publicly each year on how we're doing. Each compact will reflect local priorities and include a common set of commitments:
- Pay our own way on energy and infrastructure. We'll pay the full cost of the electricity we use and the infrastructure needed to serve us. Before major spending begins, we'll provide financial assurances so other customers are protected if a project is delayed, reduced, or canceled.
- Protect local resources and report on our impact. We'll develop a water plan for each campus, prioritize closed-loop or low-water cooling, and publish site-level water and electricity use. We'll publish construction plans and independent noise studies before operations begin and annually afterward. And we will not use non-disclosure agreements (NDAs) with public officials, allowing only narrow protections covering legitimate security information, trade secrets, or proprietary or competitively sensitive information.
- Create opportunities for local workers and businesses. We'll publish the jobs we expect to create, work with unions and training providers to help residents prepare for them, and report annually on hiring and apprenticeships. We'll also make sustained investments in priorities residents help select.
[...] The investments that help America compete globally can also help communities prosper locally. That starts with giving residents a say while plans can still change and a way to hold developers accountable for delivering on their commitments. That's what we're committing to at the campuses we own and operate, and what we believe people should be able to count on wherever AI infrastructure is built across the country.
[ Read more of this story ]( https://politics.slashdot.org/story/26/11/05/2150249/openai-responds-to-us-midterm-elections-with-new-commitment-to-communities?utm_source=atom1.0moreanon&utm_medium=feed ) at Slashdot.
# OpenSSH Flaw Lets Attackers Log Into Password-Disabled Linux Accounts
robot (spnet, 1) → All – 22:22:01 2026-11-05
A newly disclosed OpenSSH flaw dubbed "*sshole" can allow attackers to log in to password-disabled accounts on certain musl-based Linux systems simply by submitting a password longer than 256 bytes. "Apparently certain varieties of musl Linux (Alpine, OpenWrt, Buildroot, Yocto, etc.) have had this OpenSSH vulnerability for about a decade," writes longtime Slashdot reader AlteredEgg. "Upgrade now!" BleepingComputer reports: Security researcher Ozgun Kultekin, who discovered and released details on the vulnerability today, says the flaw has existed since 2016 and stems from how OpenSSH handles password verification errors on systems using the musl C library. Linux accounts can be configured to prevent password logins by replacing their password hash with an asterisk (*) in the /etc/shadow file. Because this is not a valid password hash, no password should allow access to those accounts. However, a patch introduced in OpenSSH in 2016 to fix a username enumeration vulnerability tracked as CVE-2016-6210 changed how OpenSSH handled accounts without usable password hashes.
To prevent attackers from identifying valid usernames through different response times, OpenSSH was modified to perform password hashing even when an account had no usable password hash, including accounts configured with * to block password logins. The problem is that the musl C library's crypt() function also returns * when password hashing fails, including when a submitted password exceeds its 256-byte limit. This means an attacker can submit an oversized password and cause OpenSSH to compare the returned * against the account's stored *, resulting in a successful login.
To be clear, the flaw does not allow attackers to bypass passwords on accounts with valid password hashes. [...] Admins who can't immediately install the update can mitigate the issue by turning off SSH password authentication with PasswordAuthentication no in their SSH server configuration and restarting SSH. Kultekin says admins can also check for signs of exploitation by examining SSH authentication logs for password-based logins for accounts that should not allow them.
[ Read more of this story ]( https://it.slashdot.org/story/26/11/05/2140208/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts?utm_source=atom1.0moreanon&utm_medium=feed ) at Slashdot.
robot (spnet, 1) → All – 22:22:01 2026-11-05
A newly disclosed OpenSSH flaw dubbed "*sshole" can allow attackers to log in to password-disabled accounts on certain musl-based Linux systems simply by submitting a password longer than 256 bytes. "Apparently certain varieties of musl Linux (Alpine, OpenWrt, Buildroot, Yocto, etc.) have had this OpenSSH vulnerability for about a decade," writes longtime Slashdot reader AlteredEgg. "Upgrade now!" BleepingComputer reports: Security researcher Ozgun Kultekin, who discovered and released details on the vulnerability today, says the flaw has existed since 2016 and stems from how OpenSSH handles password verification errors on systems using the musl C library. Linux accounts can be configured to prevent password logins by replacing their password hash with an asterisk (*) in the /etc/shadow file. Because this is not a valid password hash, no password should allow access to those accounts. However, a patch introduced in OpenSSH in 2016 to fix a username enumeration vulnerability tracked as CVE-2016-6210 changed how OpenSSH handled accounts without usable password hashes.
To prevent attackers from identifying valid usernames through different response times, OpenSSH was modified to perform password hashing even when an account had no usable password hash, including accounts configured with * to block password logins. The problem is that the musl C library's crypt() function also returns * when password hashing fails, including when a submitted password exceeds its 256-byte limit. This means an attacker can submit an oversized password and cause OpenSSH to compare the returned * against the account's stored *, resulting in a successful login.
To be clear, the flaw does not allow attackers to bypass passwords on accounts with valid password hashes. [...] Admins who can't immediately install the update can mitigate the issue by turning off SSH password authentication with PasswordAuthentication no in their SSH server configuration and restarting SSH. Kultekin says admins can also check for signs of exploitation by examining SSH authentication logs for password-based logins for accounts that should not allow them.
[ Read more of this story ]( https://it.slashdot.org/story/26/11/05/2140208/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts?utm_source=atom1.0moreanon&utm_medium=feed ) at Slashdot.