I started working on a huge, 10yo< codebase with ~500k LOC, but this was mid/large company with >50 developers with framework version from 2013. Now it is ~300K(unused code removed, some parts moved outside+rewritten), framework is the latest version etc., this was done due to a very good leader with a vision. Nothing prevents you from becoming that person that fixed that infamous project.

It is ok to complain about code quality, as far as you are doing something to improve it. Don't ever complain about a previous engineer, they might have been just implementing the sh*t product was enforcing on them or company asked an inexperienced engineering to glue together this project. It is rarely that a developer knowingly and happily writes bad code. Try to improve it, it will move you towards becoming a senior sooner, nothing helps you in understand how to code more than how-not-to examples. :) Also +1 to do-not-refactor-immediately comments here, observe the project and company and write tests until you know the project and culture well enough, then either increase refactor speed thanks to your tests or separate the project into chunk as micro-services or utility libraries/modules.

Also run static analysis on the codebase, you will be amazed how much "foo defined but never used" cases there will be, remove them completely, have a close eye on production errors when you release them and role-back on smallest of suspicion something is wrong. invesitage, fix, release and repeat. :)