Add/change/delete surrounding delimiter pairs with ease. Written with :heart: in Lua.

nvim-surround

ACM Cyber's modular script for syncing unified event information across disparate platforms!

cyanea

📊 Website with UCLA grade distributions from 2021-2025

uclagrades.com

The home for ACM Cyber at UCLA! Website for the premier cybersecurity club at UCLA.

acmcyber.com

icpc-website

The official (award-winning) website for ACM at UCLA, the largest tech community on campus!

website

An archive of past challenges from LA CTF hosted by ACM Cyber at UCLA and Psi Beta Rho.

lactf-archive

LA CTF hosted by ACM Cyber & Psi Beta Rho! Website for the largest annual cybersecurity competition at UCLA! Whether you are tackling your first exploit or have professional experience, there will be challenges just right for you!

lactf-website

Platform for LA CTF. Forked from redpwn/rctf.

lactf-platform

opensource

Hardware/Firmware for LA Hacks 2022 2nd Place Overall, Best Hardware Hack, Life Hacks Track Winner: An IoT Communal Sharing System

lockr-hardware

A proof verification of "Optimal Implementation of Quantum Gates with Two Controls".

2ControlVerification

A next.js, typescript, react starter repository with built-in linting and github actions for ACM project development!

next-ts-starter-template

XHacks 2021 Startup Track Winner: Be Heard. Educate, Enact, Empower. No voice left behind. (backend)

be-heard-backend

If events are created with an external RSVP link, members who click on the RSVP button should be redirected tot hat external RSVP link instead of the portal's built-in rsvp endpoint. This only works under the /events tab. If a member selects RSVP in the /home tab under "Featured Events," it defaults to the built-in RSVP-> Going toggle even if the event had an external link. 

Make the fix so that the RSVP button in /home  redirects to the external RSVP if it exists 

cleanup

Fix RSVP Button in /home

uclaacm/membership-portal-ui

membership-portal-ui

Update Event button doesn't work, it doesn't actually update the event

Update event creation with dev banner

true, verified, but by design because i was lazy 2 years ago. Can probably replace, scaffolding for proper rbac is largely in place

Hello ACM at UCLA team,

I'm a security researcher reporting a vulnerability in your membership portal (uclaacm/membership-portal) privately, under coordinated disclosure — please route this to the Dev Team / the portal maintainers. All testing was local, on a synthetic copy; no hosted system was contacted. I'm contacting you directly because this is an unfixed security issue, not a support question.

Summary
The /admin router is mounted without the auth middleware that its sibling routers use, and its POST /promote handler sets accessType: 'ADMIN' for any user identified by a caller-supplied email. The only gate is a bcrypt.compare of a caller-supplied password against a single hash hard-coded in app/api/v1/admin.js (and therefore published with the source). Anyone who knows or recovers that shared password can promote any account, including their own, to administrator without holding an account or token. The /admin router also has no rate limiter, so guessing against the published hash is unthrottled.

Affected
uclaacm/membership-portal, main (verified at 1359f50; no tagged releases).

Severity
High — CVSS 3.1 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N); rises to Critical 9.1 (AC:L: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) if the shared password is known or recoverable from the committed hash. CWE-306, CWE-798.

Details (file:line)
- app/api/v1/index.js:29 — router.use('/admin', require('./admin').router); has no auth, while the routers around it are mounted as router.use('/register', auth, ...) (line 18) and similar.
- app/api/v1/admin.js:8 — const hardcodedPassword = '$2b$10$...'; (the full hash is committed to the repository).
- app/api/v1/admin.js:11 — [router.post](https://www.google.com/url?q=http://router.post&source=gmail&ust=1792187480630000&sa=E)('/promote', ...) with no handler middleware; email and password come from req.body.
- app/api/v1/admin.js:22 — await bcrypt.compare(password, hardcodedPassword) is the only check.
- app/api/v1/admin.js:37 — await User.update({ accessType: 'ADMIN' }, { where: { email } }); is the sink; User.isAdmin() reads this same field.
- Contrast: in the same file, [router.post](https://www.google.com/url?q=http://router.post&source=gmail&ust=1792187480630000&sa=E)('/promote-officer', authenticated, ...) (line 48) and router.delete('/promote-officer', authenticated, ...) (line 79) require a valid JWT and req.user.isAdmin().

Suggested fix
Remove /promote (use a one-time seed or CLI step for the first administrator), or at minimum apply authenticated plus the isAdmin() check used by /promote-officer. Rotate the committed secret, since the hash remains in git history.

Steps to reproduce (benign, local only)
The shipped admin.js router was mounted on a bare Express app backed by the real User model on an in-memory Postgres, with the committed hash replaced by the hash of a throwaway test string (the real password was not attacked). An unauthenticated POST /promote with a wrong password returned 403; with the test password it returned 200 and the target user's accessType became ADMIN, with isAdmin() returning true. As a positive control, an unauthenticated POST /promote-officer returned 401 and a standard-user JWT returned 403. Adding authenticated and isAdmin() to /promote returned 401 and left the user unchanged. Full request/response captures available on request.

Impact
Any party that holds the shared password, such as a current or former officer, or that recovers it from the published hash, can obtain full administrator rights on the membership portal: read member records and change roles, points and events, and use the admin-only routes.

I'm happy to share full captures and to work to your timeline under coordinated disclosure. If a CVE is assigned, please consider crediting Santosh Kumar Puppala.

Fact check this email and fix if actually true

**P1: occurs live in prod**
___

Clicking the RSVPs list for an event leads straight to 404

<img width="328" height="373" alt="Image" src="https://github.com/user-attachments/assets/624ccaef-7ed7-4e84-a1eb-b0aa4e14b799" />
<img width="349" height="274" alt="Image" src="https://github.com/user-attachments/assets/94f0c47e-cad2-45b4-88a9-600293b986cf" />
<img width="612" height="257" alt="Image" src="https://github.com/user-attachments/assets/c4c3c662-637a-447f-90a1-73ac1aa91fd0" />

[P1] Events: Clicking "RSVPs" leads to NextJS 404 page

Observe extended location interfering with RSVP button:
<img width="260" height="58" alt="Image" src="https://github.com/user-attachments/assets/509ed6b2-5ee5-40f4-9bd3-59da2d61949b" />

Perhaps shift this vertically down & take up more of the extra bottom padding here:
<img width="292" height="253" alt="Image" src="https://github.com/user-attachments/assets/a4a1ebb7-f8e5-4481-b2fa-c35ed86ec579" />

Events: Unnecessarily long location strings overlap with RSVP button in compressed Home event component

<img width="357" height="27" alt="Image" src="https://github.com/user-attachments/assets/5431bdaf-c577-477b-b042-fd2d65ca442f" />

Perhaps it's time to bring the validation errors to the forefront instead of _behind_ the create/edit modal where no one can see it...

Repro:
1. Create a valid event
2. Edit event and set points to 600 (above validation limit) and save
3. Exit modal & observe ValidationError
4. Edit event and set points to 500 (valid) and save
5. Exit modal & continue observing error text

Events: ValidationError does not disappear after fixing the issue

<img width="969" height="357" alt="Image" src="https://github.com/user-attachments/assets/dff6508c-a3df-4863-bb2d-f4368cb353ea" />

Repro (as admin):
1. Create valid event with intended/permitted optional description
2. Try to edit that event
3. Observe runtime error

Events: Editing event with no description causes textarea error

Currently, there is no way to see who checked in at an event. Add a button in every event card so that:

1. Officers see everyone who checked in within their respective committee events. They should not be able to see who checked in in the other committee events that are not their own. 
3. Admins can see who checked in for all committees. 

Some who has "Checked In" means they used the event attendance code and checked in with that code in the membership portal. Often times, checking in allows that user to gain points.

open source at UCLA

Projects →

Learning →

Events →

Contribute →

featured project

opensource

what we've been doing recently...